/8 end user assignment?
Ok, back up a second.... 126/8 Jan 05 APNIC (whois.apnic.net) inetnum: 126.0.0.0 - 126.255.255.255 netname: BBTEC descr: Japan Nation-wide Network of Softbank BB Corp. status: ALLOCATED PORTABLE changed: hm-changed@apnic.net 20050208 i thought the decade of giving class A's to large corporates had long since passed.. we've got some major network rollout coming up, i need an extra 16 million IPs, so can i get one? wtf? Steve
Stephen, If you can justify a /8, ARIN will allocate one to you (not that I speak for ARIN or anything, but that's how things work). Presumably Softbank BB justified the /8 APNIC allocated to them. Rgds, -drc On Aug 4, 2005, at 11:07 AM, Stephen J. Wilcox wrote:
Ok, back up a second....
126/8 Jan 05 APNIC (whois.apnic.net)
inetnum: 126.0.0.0 - 126.255.255.255 netname: BBTEC descr: Japan Nation-wide Network of Softbank BB Corp. status: ALLOCATED PORTABLE changed: hm-changed@apnic.net 20050208
i thought the decade of giving class A's to large corporates had long since passed.. we've got some major network rollout coming up, i need an extra 16 million IPs, so can i get one?
wtf?
Steve
Hi David, I realise that but: 1. Softbank BB is not on my radar of likely /8 candidates (of course, geography may be the reason for that) 2. We know cable companies, dsl providers and mobile companies can use this many IPs, but they generally seem to make use of NAT and IPv6. If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space. I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists.. Steve On Thu, 4 Aug 2005, David Conrad wrote:
Stephen,
If you can justify a /8, ARIN will allocate one to you (not that I speak for ARIN or anything, but that's how things work). Presumably Softbank BB justified the /8 APNIC allocated to them.
Rgds, -drc
On Aug 4, 2005, at 11:07 AM, Stephen J. Wilcox wrote:
Ok, back up a second....
126/8 Jan 05 APNIC (whois.apnic.net)
inetnum: 126.0.0.0 - 126.255.255.255 netname: BBTEC descr: Japan Nation-wide Network of Softbank BB Corp. status: ALLOCATED PORTABLE changed: hm-changed@apnic.net 20050208
i thought the decade of giving class A's to large corporates had long since passed.. we've got some major network rollout coming up, i need an extra 16 million IPs, so can i get one?
wtf?
Steve
On Thu, 4 Aug 2005, Stephen J. Wilcox wrote:
I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists..
I suspect this was done on the condition that Comcast migrate users from other IP ranges into 73/8.5, then return those older ranges to ARIN for reassignment. The net effect would be that Comcast could significantly reduce the number of routes they'd have to announce into the global BGP table. 12+ million addresses is a lot of cable modems :-) I don't work for Comcast, so this is purely conjecture on my part. jms
On 4 Aug 2005, at 14:35, Stephen J. Wilcox wrote:
2. We know cable companies, dsl providers and mobile companies can use this many IPs, but they generally seem to make use of NAT and IPv6. If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space.
I know nothing much about Softbank BB, but I do know that there is nothing in the APNIC policy which says organisations need to use NAT or RFC1918 addresses or both in their networks. It is perfectly consistent with the current APNIC policies for every network interface to have a globally-unique address. I would expect every ISP who is able to demonstrate a justifiable need for a /8 allocation be getting one. I'm not sure why you think there are ISPs who can justify a /8 that are not asking for them. I also don't know about "generally" in your first sentence above; personally I have never had DSL or GPRS service from anybody who wouldn't give me a globally-unique address and I've never seen a DSL or GPRS service which would give me any kind of IPv6 address. Are things different in the RIPE region? Joe (slightly queasy, imagining the backscatter and worm probe love you'd suddenly attract when you advertised your yet-to-be-used /8 for the first time)
On Thu, Aug 04, 2005 at 02:54:07PM -0400, Joe Abley wrote:
(slightly queasy, imagining the backscatter and worm probe love you'd suddenly attract when you advertised your yet-to-be-used /8 for the first time)
I would guesstimate about 8 Terabyte per day, judging from the traffic I saw towards a virgin /21 (1 GByte per day). Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Daniel Roesen wrote:
I would guesstimate about 8 Terabyte per day, judging from the traffic I saw towards a virgin /21 (1 GByte per day).
/18 attracts 19kbps on average, with day averages between 5 and 37 kilobits per second. That would translate to only 50 to 400 megabytes a day. So your /21 must be from a bad neighborhood. Pete
Joe> Are things different in the RIPE region? Not in this part of the RIPE region (the UK). Dynamically assigned publicly routable IPv4 addresses are the norm for residential broadband services, though some providers offer static addressing as an option, I think a couple of low end services use NAT, and one small provider (that I'm aware of) offers IPv6. GPRS is invariably NATed IPv4 here, I think. As long as you're paying by the byte, it's not clear that you'd want a publicly routable address. -roy
Steve, On Aug 4, 2005, at 11:35 AM, Stephen J. Wilcox wrote:
1. Softbank BB is not on my radar of likely /8 candidates (of course, geography may be the reason for that)
They are one of the largest ISPs in Japan and Japan (at least certain parts, like Tokyo and Osaka) is _significantly_ more advanced in terms of broadband penetration than the US.
2. We know cable companies, dsl providers and mobile companies can use this many IPs, but they generally seem to make use of NAT and IPv6. If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space.
This is, of course, why IPv6 has the traction it has. I used to be much more sanguine about IPv4 address space availability. That was long ago. Given growth patterns, the only way IPv4 will continue to be usable is by the use of NAT. For various reasons (some good, some not), NAT is seen as the spawn of the Devil. As such, IPv4 with more bits becomes less non-attractive.
I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists..
Well, there has been a flurry of /8s being allocated by the IANA to the RIRs which are announced to the various operational mailing lists. I think it safe to assume those /8 allocations are not being done to redistribute the remaining free pool to the RIRs... [In case anyone is wondering, no, I do not have any inside knowledge of this as an ARIN Board of Trustees Member -- the Board is explicitly segregated from the day-to-day operational aspects of ARIN] Rgds, -drc
i just -know- i should read the rest of this thread before considering a reply. if i remember correctly, some group in Japan received a /8 as a transition plan to IPv6... details are hazy. sort of like the ARIN thing for experiments, the v4 space was/is supposed to be tied to some equivalent v6 space and after a period (12 months or so) the v4 space was to be returned. Pretty clever as a transition thing, presuming no ill will on the part of the participants. --bill
hi
if i remember correctly, some group in Japan received a /8 as a transition plan to IPv6... details are hazy. sort of like the ARIN thing for experiments, the v4 space was/is supposed to be tied to some equivalent v6 space and after a period (12 months or so) the v4 space was to be returned. Pretty clever as a transition thing, presuming no ill will on the part of the participants.
you are remembering correctly, and there were discussions about this at the last APNIC OPM. details can be found here if you are interested. http://www.apnic.net/meetings/19/programme/sigs/ipv6.html several ASs participated in this so called "large space IPv4 trial usage". --- seiichi kawamura:-)
there were discussions about this at the last APNIC OPM. details can be found here if you are interested. http://www.apnic.net/meetings/19/programme/sigs/ipv6.html several ASs participated in this so called "large space IPv4 trial usage".
indeed, this was a very interesting, if somewhat odd, presentation. e.g. the growth graphs had no labels on the y axes:-). my impression was that it was essentially a request to extend the time of the trial because it was moving more slowly than expected. "we promised to return the space, but please give us more time." randy
hi randy!
indeed, this was a very interesting, if somewhat odd, presentation. e.g. the growth graphs had no labels on the y axes:-).
oops. we'll have to tell kousuke-san. :-)
my impression was that it was essentially a request to extend the time of the trial because it was moving more slowly than expected. "we promised to return the space, but please give us more time."
yes i remember that was the goal of the discussion (which there was very little of) at the last APNIC. not much opposing opinion was heard if there were any. but the presentation itself had interesting information about why and how these IPv4 addresses were being used so I thought I should point it out. --- seiichi (i contribute to the ipv6 promotion council but in a different working group)
On Thu, 4 Aug 2005, David Conrad wrote: > They are one of the largest ISPs in Japan. And this helps them justify a /8 _in the US_ how? -Bill
? % whois -h whois.arin.net 126.0.0.0 OrgName: Asia Pacific Network Information Centre OrgID: APNIC Address: PO Box 2131 City: Milton StateProv: QLD PostalCode: 4064 Country: AU ReferralServer: whois://whois.apnic.net NetRange: 126.0.0.0 - 126.255.255.255 CIDR: 126.0.0.0/8 NetName: APNIC-126 NetHandle: NET-126-0-0-0-1 Parent: NetType: Allocated to APNIC NameServer: DNS03.BBTEC.NET NameServer: DNS04.BBTEC.NET NameServer: SEC1.APNIC.NET Comment: This IP address range is not registered in the ARIN database. Comment: For details, refer to the APNIC Whois Database via Comment: WHOIS.APNIC.NET or http://www.apnic.net/apnic-bin/whois2.pl Comment: ** IMPORTANT NOTE: APNIC is the Regional Internet Registry Comment: for the Asia Pacific region. APNIC does not operate networks Comment: using this IP address range and is not able to investigate Comment: spam or abuse reports relating to these addresses. For more Comment: help, refer to http://www.apnic.net/info/faq/abuse RegDate: 2005-01-27 Updated: 2005-04-29 OrgTechHandle: AWC12-ARIN OrgTechName: APNIC Whois Contact OrgTechPhone: +61 7 3858 3100 OrgTechEmail: search-apnic-not-arin@apnic.net On Aug 5, 2005, at 12:35 AM, Bill Woodcock wrote:
On Thu, 4 Aug 2005, David Conrad wrote:
They are one of the largest ISPs in Japan.
And this helps them justify a /8 _in the US_ how?
-Bill
On Fri, 5 Aug 2005, David Conrad wrote: > % whois -h whois.arin.net 126.0.0.0 > OrgName: Asia Pacific Network Information Centre > > And this helps them justify a /8 _in the US_ how? Ah, I'd misunderstood, from all the talk about ARIN, I thought somehow ARIN was involved. -Bill
On Fri, 5 Aug 2005, David Conrad wrote:
?
% whois -h whois.arin.net 126.0.0.0
OrgName: Asia Pacific Network Information Centre
ReferralServer: whois://whois.apnic.net
NetRange: 126.0.0.0 - 126.255.255.255 CIDR: 126.0.0.0/8 On Aug 5, 2005, at 12:35 AM, Bill Woodcock wrote:
On Thu, 4 Aug 2005, David Conrad wrote:
They are one of the largest ISPs in Japan.
And this helps them justify a /8 _in the US_ how?
probably this confusion comes due to some overload/misuse of 'arin' where 'local rir' should have been used, like apnic in this case :) It's oscillated between the two 3 or 4 times in this discussion.
On Thu, Aug 04, 2005 at 07:35:24PM +0100, Stephen J. Wilcox wrote:
1. Softbank BB is not on my radar of likely /8 candidates (of course, geography may be the reason for that)
Indeed, ASPAC is off most of our radars. :) Given the size of Softbanks subscriber base, I'm not surprised about the /8 alloc at all.
2. We know cable companies, dsl providers and mobile companies can use this many IPs, but they generally seem to make use of NAT and IPv6.
So you ask folks to resort to hacks like NAT or force IPv6-only to their users when there is still a lack-of-content problem there? Can you show me your business plan draft for that? I'm curious. :-)
If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space.
We are already, but you seem to have your head firmly sticking in the sand, together with the content providers. :-) It looks like IPv4 space really needs to "run out" before the residential access ISPs are really being forced to IPv6 and thus the content providers wake up too. BTW, Softbank got 2400:2000::/20.
I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists..
Why should they? Business as usual. :-) I hope that more ISPs stop doing NAT/RFC1918 and just request whatever they need. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Thu, 4 Aug 2005, Daniel Roesen wrote:
So you ask folks to resort to hacks like NAT or force IPv6-only to their users when there is still a lack-of-content problem there? Can you show me your business plan draft for that? I'm curious. :-)
ok, thats not what i mean.. i am saying /8,/9 etc are not normal
If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space.
We are already, but you seem to have your head firmly sticking in the sand, together with the content providers. :-)
i thought we had years to go according to some decent sources?
It looks like IPv4 space really needs to "run out" before the residential access ISPs are really being forced to IPv6 and thus the content providers wake up too.
BTW, Softbank got 2400:2000::/20.
I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists..
Why should they? Business as usual. :-)
I hope that more ISPs stop doing NAT/RFC1918 and just request whatever they need.
how long does it take such an org to use 16 million IPs? based on the above comment of '..need to run out' should they not maybe get 1million then come back when they use it all to give some other folks a chance? i'm not suggesting denying anyone the IPs they require but i am suggesting we shouldnt steam ahead into exhaustion either Steve
On Thu, Aug 04, 2005 at 09:26:48PM +0100, Stephen J. Wilcox wrote:
So you ask folks to resort to hacks like NAT or force IPv6-only to their users when there is still a lack-of-content problem there? Can you show me your business plan draft for that? I'm curious. :-)
ok, thats not what i mean.. i am saying /8,/9 etc are not normal
Not common, but not !normal, IMHO. As others stated, Softbank has some 11 million subscribers. What if they plan to get rid of the dynamic IP thing and offer proper static addresses by default? Then a /8 is not at all "weird" but just necessary.
If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space.
We are already, but you seem to have your head firmly sticking in the sand, together with the content providers. :-)
i thought we had years to go according to some decent sources?
Famous last words when driving down a long road towards a firm wall of concrete. You want to rush then? Do you wait for the pain to fully extend? I prefer orderly, planned, concious migrations, not a state of "uhm, we cannot get new IPv4 address space anymore, and the grey market prices for IPv4 space is skyrocketing... I cannot afford it anymore and our customers switch to ISPs who can still". I thing that things will become very very nasty when we not only see the wall on our map but actually see it coming quickly on the horizont and warning signs at the side of the road tell something about "last exit to IPv6 in x miles. Toll applicable.".
I hope that more ISPs stop doing NAT/RFC1918 and just request whatever they need.
how long does it take such an org to use 16 million IPs?
With 11 million subscribers? How long does it take to write and run a script to associate a unique IP to every customer in the RADIUS database?
based on the above comment of '..need to run out' should they not maybe get 1million then come back when they use it all to give some other folks a chance?
A chance for what? You can get IPs for your customers too. Have a million customers, get a million addresses (and more, because of the hierarchy tax). IPv4 will exhaust. Get yourself comfortable with this idea and plan to be fully ready for IPv6 service way before that happens.
i'm not suggesting denying anyone the IPs they require but i am suggesting we shouldnt steam ahead into exhaustion either
Well, I'm quite sure ARIN didn't hand out the addresses just to "steam ahead in to exhaustion". Unlike with IPv6 where your customer count is enough to justify address space, in IPv4 you also have to "proof" that you will actually use the address space too. So I speculate that they will have provided enough evidence that they are going to actually use this IP space within the next couple of years. Their IPv6 allocation pretty nicely aligns to their subscriber count btw. According to HD-Ratio you'll need (IIRC) >5.5 million customers or so for a /20. Perhaps some Softbank folks want to provide some insight in the plans surrounding this chunk of IPv4 address space? Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 8/4/05 4:46 PM, "Daniel Roesen" <dr@cluenet.de> wrote:
Famous last words when driving down a long road towards a firm wall of concrete. You want to rush then? Do you wait for the pain to fully extend? I prefer orderly, planned, concious migrations, not a state of "uhm, we cannot get new IPv4 address space anymore, and the grey market prices for IPv4 space is skyrocketing... I cannot afford it anymore and our customers switch to ISPs who can still".
I thing that things will become very very nasty when we not only see the wall on our map but actually see it coming quickly on the horizont and warning signs at the side of the road tell something about "last exit to IPv6 in x miles. Toll applicable.".
This is a good reason for every major service provider to request some IPv6 space, ensure that future equipment acquisitions support v6, and have someone playing with it in the lab. Not a very good reason to deploy. Why do so many v6 folks fill their arguments with notes of alarmism? Why don't we just make an orderly migration when it is called for, rather than using hyperbole to scare people? Of course, making IPv4 a fungible commodity would help with this (yes, I'm a broken record). When prices get too high, you know its time for v6.
Regards, Daniel
-- Daniel Golding
On Fri, 05 Aug 2005 12:17:55 EDT, Daniel Golding said:
Why do so many v6 folks fill their arguments with notes of alarmism? Why don't we just make an orderly migration when it is called for, rather than using hyperbole to scare people?
We tried that a few years ago. Nobody moved. So we come to this point: On Fri, 05 Aug 2005 10:44:54 +0200, Iljitsch van Beijnum said:
Five years is a long time, you can upgrade a lot of load balancers in such a period. You can upgrade a good number in three years, too.
Only if you get started *now*. Spending another 18 months figuring out your deployment strategy cuts significantly into what you can get done in 3 years.
Why do so many v6 folks fill their arguments with notes of alarmism?
old bad habits. the sky has been falling for a decade now. the problem is it makes it hard to separate signal from noise. e.g. after many years of telling us 3gpp was about to be a major address space eater, we stopped listening. but, this year, 3gpp is finally getting some roll-out in a number of countries. what we have yet to hear (from the actual operators, not the sky is falling ipv6 marketeers) is how those deployments are architecting the routing and address space. randy
On Fri, Aug 05, 2005 at 12:17:55PM -0400, Daniel Golding wrote:
Why do so many v6 folks fill their arguments with notes of alarmism? Why don't we just make an orderly migration when it is called for, rather than using hyperbole to scare people?
I rather infer, Daniel, that the issue is "how long the lane change will take", and therefore how far in advance of the wall the migration needs to start (and how fast it needs to ramp) in order to, in fact, *be* orderly. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Thu, 4 Aug 2005, Daniel Roesen wrote:
On Thu, Aug 04, 2005 at 07:35:24PM +0100, Stephen J. Wilcox wrote:
2. We know cable companies, dsl providers and mobile companies can use this many IPs, but they generally seem to make use of NAT and IPv6.
So you ask folks to resort to hacks like NAT or force IPv6-only to their users when there is still a lack-of-content problem there? Can you show me your business plan draft for that? I'm curious. :-)
I meant to ask this at a nanog or this IETF... why don't some of the larger content providers (google, msn, yahoo, to name 3 examples) put AAAA records in for their maint content pieces? why don't they get v6 connectivity from their providers (that offer such services) ? There are starting to be more and more folks with v6 connectivity... it'd be interesting as a way to drive usage on v6, eh?
BTW, Softbank got 2400:2000::/20.
holy freeholy! good thing v6 space is 'infinite' eh? :) -Chris
I meant to ask this at a nanog or this IETF... why don't some of the larger content providers (google, msn, yahoo, to name 3 examples) put AAAA records in for their maint content pieces? why don't they get v6 connectivity from their providers (that offer such services) ? There are starting to be more and more folks with v6 connectivity... it'd be interesting as a way to drive usage on v6, eh?
(I work for a not-quite-as-large content player. These are my own opinions, but this is what I'd tell my empolyer if they asked.) - We can't get provider-independent IPv6 space (without pretending to be a service provider.) - None of our transit providers appear to provide IPv6 transit. Or if they do, they keep it pretty quiet. (Does UUNET?) - Most of our content is delivered via load balancer hardware that would also need to support IPv6. Last time I checked, it didn't. - There are (perceived to be) more important things to spend our limited resources on. Steve
On Thu, Aug 04, 2005 at 03:49:48PM -0700, Steve Feldman wrote: ...
- None of our transit providers appear to provide IPv6 transit. Or if they do, they keep it pretty quiet. (Does UUNET?) ...
ISTM that one of their incarnations briefed this to us as a product, years ago. [Chris?] -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
On Thu, 4 Aug 2005, Joseph S D Yao wrote:
On Thu, Aug 04, 2005 at 03:49:48PM -0700, Steve Feldman wrote: ...
- None of our transit providers appear to provide IPv6 transit. Or if they do, they keep it pretty quiet. (Does UUNET?) ...
ISTM that one of their incarnations briefed this to us as a product, years ago. [Chris?]
that might have been vbns+... but uunet proper supports v6 in one form or another currently...
On Thu, 4 Aug 2005, Steve Feldman wrote:
I meant to ask this at a nanog or this IETF... why don't some of the larger content providers (google, msn, yahoo, to name 3 examples) put AAAA records in for their maint content pieces? why don't they get v6 connectivity from their providers (that offer such services) ? There are starting to be more and more folks with v6 connectivity... it'd be interesting as a way to drive usage on v6, eh?
(I work for a not-quite-as-large content player. These are my own opinions, but this is what I'd tell my empolyer if they asked.)
- We can't get provider-independent IPv6 space (without pretending to be a service provider.)
oh, and multi-6/shim6 isn't going to help you do PA space and multihome? really? it isn't? hmm, time to get vocal i suppose, eh?
- None of our transit providers appear to provide IPv6 transit. Or if they do, they keep it pretty quiet. (Does UUNET?)
we do, verio does, sprint does... at&t might (my memory is dim there, sorry) L3 does. Some is more 'interim' tunnel based access unless you are in/near the right place on the respective map/net... others are 'native' (verio comes to mind in this regard)
- Most of our content is delivered via load balancer hardware that would also need to support IPv6. Last time I checked, it didn't.
will the v6 access really be enough to require LB's? or are they there for other reasons (global lb for content close to customers, regionalized content) perhaps reasons which would matter 'less' in an initial v6 world where you were getting the lb's fixed by their vendor? (or finding a vendor that supports v6 lb?)
- There are (perceived to be) more important things to spend our limited resources on.
ah, the ever popular: "Waiting for the killer application" again... sure, I understand this.
On Thu, 4 Aug 2005, Christopher L. Morrow wrote:
On Thu, 4 Aug 2005, Steve Feldman wrote:
- Most of our content is delivered via load balancer hardware that would also need to support IPv6. Last time I checked, it didn't. will the v6 access really be enough to require LB's? or are they there for other reasons (global lb for content close to customers, regionalized content) perhaps reasons which would matter 'less' in an initial v6 world where you were getting the lb's fixed by their vendor? (or finding a vendor that supports v6 lb?)
If you have a large web site (say top 2000) or mail system ( or other apps) then you will almost certainly have your connections going via a load balancer. You have specialized servers for front end, images, database, data, caching, authentication etc. You'll probably have multiple examples of each, load balanced so that if one goes down nobody notices. Here is a simple example: http://meta.wikimedia.org/wiki/Image:Wikimedia-servers-2005-04-12.png Creating a seperate instance or path though all that for IPv6 is probably going to be hard if it is all setup for everything to go one way. On the other hand if your load balancer is IPv6 aware then the stuff behind it might not need to be since it can NAT incoming request to ipv4. -- Simon J. Lyall. | Very Busy | Mail: simon@darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.
On 4 Aug 2005, at 21:51, Simon Lyall wrote:
Creating a seperate instance or path though all that for IPv6 is probably going to be hard if it is all setup for everything to go one way.
I know people who have set up such things using reverse proxies (listen on v6 for query, relay request to v4 server farm via existing load balancer). No need to touch the production v4 server infrastructure to bring this live, although there's a need for a production AAAA record, if you want to try it with real clients. There was a time when www.isc.org was hosted on an OS which had no (or problematic, I forget) v6 support, and that's how we did it. With layer-2 load balancers and v6-capable servers, attaching the service address to just one machine in the cluster might do the trick, as a way of trying stuff out. As has been mentioned, the likely load of v6 traffic is low. However, experience with the growth characteristics would presumably trigger business cases and requests to vendors if/when appropriate; no experience means less opportunity to plan and budget. How do you (proverbial, general, plural) really know what demand there is for v6 access to your services unless you turn it on and find out? Joe
On Fri, 5 Aug 2005, Joe Abley wrote:
On 4 Aug 2005, at 21:51, Simon Lyall wrote:
Creating a seperate instance or path though all that for IPv6 is probably going to be hard if it is all setup for everything to go one way.
I know people who have set up such things using reverse proxies (listen on v6 for query, relay request to v4 server farm via existing load balancer). No need to touch the production v4 server infrastructure to bring this live, although there's a need for a production AAAA record, if you want to try it with real clients. There was a time when www.isc.org was hosted on an OS which had no (or problematic, I forget) v6 support, and that's how we did it.
This sort of thing is what I was thinking would get things rolling for some of the content providers. Something 'short term' while you work out some of the transit issues, technical issues with apps/os/network/blah... but something toget some v6 traffic aside from ping :)
With layer-2 load balancers and v6-capable servers, attaching the service address to just one machine in the cluster might do the trick, as a way of trying stuff out.
yup, another option as well, provided the LB's support v6, which is apparently problematic :(
As has been mentioned, the likely load of v6 traffic is low. However, experience with the growth characteristics would presumably trigger business cases and requests to vendors if/when appropriate; no experience means less opportunity to plan and budget. How do you (proverbial, general, plural) really know what demand there is for v6 access to your services unless you turn it on and find out?
and how do the problems get worked out without deployment?
On Fri, 5 Aug 2005, Joe Abley wrote:
Creating a seperate instance or path though all that for IPv6 is probably going to be hard if it is all setup for everything to go one way.
I know people who have set up such things using reverse proxies (listen on v6 for query, relay request to v4 server farm via existing load balancer).
The "standard" KAME v6 stack comes with a network interface for exactly this purpose: "faith". It provides essentially an all-ports proxy from a v6 TCP client to a v4 TCP server. Its original stated purpose is to provide access to v4 for a v6-only local net, but it can be trivially used on the other end to provide a v6 inbound connection point for a local v4-only server. Perhaps a "load balancer v6 wrapper"? -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
Christopher L. Morrow wrote:
will the v6 access really be enough to require LB's? or are they there for other reasons (global lb for content close to customers, regionalized content) perhaps reasons which would matter 'less' in an initial v6 world where you were getting the lb's fixed by their vendor? (or finding a vendor that supports v6 lb?)
I am a keyboard jockey for an international online retailer; I picked our loadbalancer solution[0] because of the things it did other than balancing load per se, including cacheing, tcp and ssl session offloading, and content compression. Yes, you could do much of this with apache/mod_proxy but not 'as well'. Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries. [0] Redline Networks E|X, now owned by Juniper of Borg. -a
Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries.
could you comment on christopher's observation that, given the likely volume of v6 traffic, you would not have a v6 load worth balancing? of course, then you would be committed to serving v6. and if loads increased before you got vendor support for balancing, you would not be in a pretty place. randy
On 5-aug-2005, at 10:59, Randy Bush wrote:
Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries.
could you comment on christopher's observation that, given the likely volume of v6 traffic, you would not have a v6 load worth balancing? of course, then you would be committed to serving v6. and if loads increased before you got vendor support for balancing, you would not be in a pretty place.
Is there any particular reason why a service over IPv6 couldn't be load balanced by putting a good number of AAAA records in the DNS? Since most IPv6-capable browsers have decent support for trying multiple addresses, the problem of having a server be unavailable but still be in the DNS wouldn't be as bad as in IPv4. Obviously when people running these services refuse to consider IPv6 because they can't load balance doesn't provide much incentive to load balance vendors to upgrade their stuff.
On Fri, 5 Aug 2005, Iljitsch van Beijnum wrote:
could you comment on christopher's observation that, given the likely volume of v6 traffic, you would not have a v6 load worth balancing?
Is there any particular reason why a service over IPv6 couldn't be load balanced by putting a good number of AAAA records in the DNS?
_Eventually_, DNS packet size and a desire to avoid truncation at that level would stop you. Nothing stopping you from having say 4 As and 3 AAAAs attached to one www record though. Personally, I think that having two AAAA records will hold you in place for long enough that vendors will catch up with decent AAAA load balancing support, unless of course you get hit by the mythical IPv6 killer app in the meantime. --==-- Bruce.
On Fri, 5 Aug 2005, Bruce Campbell wrote:
On Fri, 5 Aug 2005, Iljitsch van Beijnum wrote:
could you comment on christopher's observation that, given the likely volume of v6 traffic, you would not have a v6 load worth balancing?
Is there any particular reason why a service over IPv6 couldn't be load balanced by putting a good number of AAAA records in the DNS?
_Eventually_, DNS packet size and a desire to avoid truncation at that level would stop you. Nothing stopping you from having say 4 As and 3 AAAAs attached to one www record though.
Personally, I think that having two AAAA records will hold you in place for long enough that vendors will catch up with decent AAAA load balancing support, unless of course you get hit by the mythical IPv6 killer app in the meantime.
Assuming that the mythical v6 killer app requires the use of the dns at all... distributed p2p overlay networks don't make much use of the dns now for service and resource location, it's seems likely that they won't on v6 either.
--==-- Bruce.
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
On 5-aug-2005, at 11:33, Bruce Campbell wrote:
Is there any particular reason why a service over IPv6 couldn't be load balanced by putting a good number of AAAA records in the DNS?
_Eventually_, DNS packet size and a desire to avoid truncation at that level would stop you. Nothing stopping you from having say 4 As and 3 AAAAs attached to one www record though.
Note that the issues for regular requests are very different from those that make adding AAAA record to the root servers more difficult. Since clients are either asking for A or AAAA in any given request, the two won't generally sit together in the same packet. I'm not sure how much room additional AAAA records take up, but I think it's a little under 30 bytes. At this rate, there is no way you're going to run out of 512 bytes with less than 10 AAAA records. Then there is EDNS0, and failing that, TCP.
Personally, I think that having two AAAA records will hold you in place for long enough that vendors will catch up with decent AAAA load balancing support, unless of course you get hit by the mythical IPv6 killer app in the meantime.
Mythical killer apps only need mythical bandwidth so a mythical load balancer suffices. :-)
On Fri, Aug 05, 2005 at 12:05:08PM +0200, Iljitsch van Beijnum wrote: Hi,
I'm not sure how much room additional AAAA records take up, but I think it's a little under 30 bytes. At this rate, there is no way you're going to run out of 512 bytes with less than 10 AAAA records. Then there is EDNS0, and failing that, TCP.
With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS. -- Sabri Berisha, Juniper Certified - JNCIA #747 | Cisco Certified - CCNA email: sabri@cluecentral.net | cell: +31 6 19890416 http://www.cluecentral.net/ | http://www.virt-ix.net/
On Fri, 5 Aug 2005, Sabri Berisha wrote: > With the use of anycast DNS servers on the internet, TCP is no longer an > option for DNS. Bzzzt. Try again. -Bill
On Fri, Aug 05, 2005 at 04:10:46AM -0700, Bill Woodcock wrote:
On Fri, 5 Aug 2005, Sabri Berisha wrote: > With the use of anycast DNS servers on the internet, TCP is no longer an > option for DNS.
Bzzzt. Try again.
/--[cabernet]--[merlot]--[riesling]--[server 1] [end-host] ----- [shiraz] | \--[sangria]]--[chardonnay]--[bordeaux]--[server 2] Imagine a TCP session between end-host and server 1. The path is asymmetric: traffic from end-host to server 1 flows as shiraz->cabernet->merlot->riesling->server 1 traffic from server 1 to end-host flows as riesling->merlot->chardonnay->sangria->shiraz->end-host end-host does a dns request, and server 1 answers. There are now 2 things which can theoretically break: 1. route change Suppose merlot looses adjacency with riesling. It will then send the tcp-packets from end-host to server 2, which has now knowledge of the session and return a RST 2. mtu problems Suppose server 1 returns a packet with an size of X bytes. Suppose Chardonnay has an mtu of X-1 to Sangria. Chardonnay will then send a packet-too-large to the server 1. But what if Chardonnay has a better route via Bordeaux instead of via Merlot? The icmp packet will not arrive at server 1 and the request will time out. Yes, this is theoretically. Yes the request will definately be retransmitted. But it can brake, so imho anycast dns using tcp is not a wise thing to do. -- Sabri Berisha, Juniper Certified - JNCIA #747 | Cisco Certified - CCNA email: sabri@cluecentral.net | cell: +31 6 19890416 http://www.cluecentral.net/ | http://www.virt-ix.net/
On 5 Aug 2005, at 07:54, Sabri Berisha wrote:
On Fri, Aug 05, 2005 at 04:10:46AM -0700, Bill Woodcock wrote:
On Fri, 5 Aug 2005, Sabri Berisha wrote:
With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS.
Bzzzt. Try again.
/--[cabernet]--[merlot]--[riesling]--[server 1] [end-host] ----- [shiraz] | \--[sangria]]--[chardonnay]--[bordeaux]--[server 2]
It is of course possible to construct networks through which TCP behaves very poorly with anycasted services. This does not mean that TCP is fundamentally incompatible with anycast. There are plenty of examples of people anycasting services which involve long-held TCP sessions (like FTP servers, and HTTP server serving large media files). Naturally not all networks and not all node placement decisions will work for these kinds of services, but it is certainly possible to use anycast to great effect with very high service quality. See draft-grow-ietf-anycast-01 for more commentary. Joe
On 5-aug-2005, at 15:55, Joe Abley wrote:
It is of course possible to construct networks through which TCP behaves very poorly with anycasted services. This does not mean that TCP is fundamentally incompatible with anycast.
It does mean that if people want to anycast services that run over TCP (even just a small part of the time, such as DNS) they should make sure this works well. A good start is using different AS numbers for the anycast instances so (Cisco) routers won't load balance over the different paths. But all of this is irrelevant to the discussion at hand, unless I missed something big and DNS over TCP has now been deprecated. If that's the case, the appropriate action is to disable TCP queries in the software, not to avoid TCP queries by keeping response sizes small. But my original point was that you won't go over the non-EDNS0 limit for normal queries with less than a dozen AAAA records anyway.
iljitsch@muada.com (Iljitsch van Beijnum) writes:
On 5-aug-2005, at 15:55, Joe Abley wrote:
It is of course possible to construct networks through which TCP behaves very poorly with anycasted services. This does not mean that TCP is fundamentally incompatible with anycast.
It does mean that if people want to anycast services that run over TCP (even just a small part of the time, such as DNS) they should make sure this works well.
it's working fine for 30+ instances of F-root.
A good start is using different AS numbers for the anycast instances so (Cisco) routers won't load balance over the different paths.
we have not encountered a problem like this, even though all F-root anycast instances use a consistent origin-AS. my belief, previously explained here, is that anyone who turns on multipath-EGP (rather than multipath-IGP) is going to have a boatload of other problems before they ever get around to noticing whether TCP is working toward anycasted servers. (OSPF ECMP is, i believe, on-by-default; multipath-BGP is, i am sure, off-by-default.)
But all of this is irrelevant to the discussion at hand, unless I missed something big and DNS over TCP has now been deprecated. If that's the case, the appropriate action is to disable TCP queries in the software, not to avoid TCP queries by keeping response sizes small.
agreed. (that TCP isn't a problem.)
But my original point was that you won't go over the non-EDNS0 limit for normal queries with less than a dozen AAAA records anyway.
disagreed. (because DNSSEC is coming.) -- Paul Vixie
On Fri, Aug 05, 2005 at 04:10:46AM -0700, Bill Woodcock wrote:
On Fri, 5 Aug 2005, Sabri Berisha wrote: > With the use of anycast DNS servers on the internet, TCP is no longer an > option for DNS.
Bzzzt. Try again.
Naw; c'mon, guys: we did this one *last* month; I still have the proof in my archives. :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Fri, 5 Aug 2005, Sabri Berisha wrote:
On Fri, Aug 05, 2005 at 12:05:08PM +0200, Iljitsch van Beijnum wrote:
Hi,
I'm not sure how much room additional AAAA records take up, but I think it's a little under 30 bytes. At this rate, there is no way you're going to run out of 512 bytes with less than 10 AAAA records. Then there is EDNS0, and failing that, TCP.
With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS.
oddly enough there's been some research on this subject. you might not in fact be able to conclude that if your routing is sufficiently stable.
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
On Fri, 5 Aug 2005, Joel Jaeggli wrote:
On Fri, 5 Aug 2005, Sabri Berisha wrote:
With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS.
oddly enough there's been some research on this subject. you might not in fact be able to conclude that if your routing is sufficiently stable.
sorry forgot the attribution http://rip.psg.com/~randy/050223.anycast-apnic.pdf http://www.nanog.org/mtg-0505/pdf/karrenberg.pdf
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
joelja@darkwing.uoregon.edu (Joel Jaeggli) wrote:
With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS.
oddly enough there's been some research on this subject. you might not in fact be able to conclude that if your routing is sufficiently stable.
Actually, if you don't allow/do zone transfers (which we don't), TCP/DNS sessions are sufficiently short-lived to function properly. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Sabri Berisha <sabri@cluecentral.net> wrote: [...]
With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS.
Erm, bollocks. Just because a few nameservers are anycasted doesn't mean that the vast majority of non-anycasted servers may not use TCP. Optimising the common case of simple lookups so they fit in a UDP request makes good sense, but an overzealous determination to stamp out TCP DNS is not helpful, since it is rather useful under certain circumstances. -- Congratulations. Astronomers have detected pressure waves whose frequency is something like 57 octaves below middle C in the core of another galaxy, but you've found a lower tone than that. - Steve VanDevender in the Monastery
On Fri, Aug 05, 2005 at 11:51:53AM +0000, abuse@cabal.org.uk wrote:
Sabri Berisha <sabri@cluecentral.net> wrote: [...]
With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS.
Erm, bollocks.
Just because a few nameservers are anycasted doesn't mean that the vast majority of non-anycasted servers may not use TCP.
Oh I can't agree with that more. No problem in using tcp for non-anycasted servers..
Optimising the common case of simple lookups so they fit in a UDP request makes good sense, but an overzealous determination to stamp out TCP DNS is not helpful, since it is rather useful under certain circumstances.
I agree here, -- Sabri Berisha, Juniper Certified - JNCIA #747 | Cisco Certified - CCNA email: sabri@cluecentral.net | cell: +31 6 19890416 http://www.cluecentral.net/ | http://www.virt-ix.net/
On Fri, 5 Aug 2005 abuse@cabal.org.uk wrote:
Sabri Berisha <sabri@cluecentral.net> wrote: [...]
With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS.
Erm, bollocks.
Just because a few nameservers are anycasted doesn't mean that the vast majority of non-anycasted servers may not use TCP.
Optimising the common case of simple lookups so they fit in a UDP request makes good sense, but an overzealous determination to stamp out TCP DNS is not helpful, since it is rather useful under certain circumstances.
*cough* worldnic dns servers *cough* it's part of the rfc, make sure it works please.
--On August 5, 2005 12:50:08 PM +0200 Sabri Berisha <sabri@cluecentral.net> wrote:
On Fri, Aug 05, 2005 at 12:05:08PM +0200, Iljitsch van Beijnum wrote:
Hi,
I'm not sure how much room additional AAAA records take up, but I think it's a little under 30 bytes. At this rate, there is no way you're going to run out of 512 bytes with less than 10 AAAA records. Then there is EDNS0, and failing that, TCP.
With the use of anycast DNS servers on the internet, TCP is no longer an option for DNS.
Most of us aren't using anycast DNS....for those that are, they know the limitations and problems they face. Though, realistically, for most people I'd bet it's a non-issue anyway. Most replies, including glue/additionals are probably far less than the links packet size in most places. There are exceptions. There are always exceptions. :)
Oh how I relish the firebomb email while on vacation trick :) On Fri, 5 Aug 2005, Iljitsch van Beijnum wrote:
On 5-aug-2005, at 10:59, Randy Bush wrote:
Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries.
could you comment on christopher's observation that, given the likely volume of v6 traffic, you would not have a v6 load worth balancing? of course, then you would be committed to serving v6. and if loads increased before you got vendor support for balancing, you would not be in a pretty place.
--snip dns multi-AAAA tricks---
Obviously when people running these services refuse to consider IPv6 because they can't load balance doesn't provide much incentive to load balance vendors to upgrade their stuff.
I think most of the problem gets to: "Vendor XYZ, we need ipv6 support in your hardware loadbalancer product." "Customer ABC, hrm, COOL! when are you deploying v6?" "Vendor XYZ, well, we aren't ready YET, but perhaps when we get down to item 234 on our priorities list we will be ready, say 5 years from now? provided other projects don't slip and marketting doesn't throw another monkey wrench in my project list :(" "Customer ABC, sure...w e'll get right on that then.... wanna see a shiney new lb product fact sheet?..." without immediate needs and immediate testing/work I doubt vendors will push in this new feature :( I may be cynical though...
On 6-aug-2005, at 21:56, Randy Bush wrote:
i.e. how much will doing v6 add to the lb company's income?
Business is so much easier when it comes with guarantees about the future. I.e. sometimes you need to invest in new technology without immediate clear benefits to remain relevant in the long term. We all know that it's rarely the first adopter that makes the most money off of something new, but it's never the last.
Randy Bush wrote:
Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries. could you comment on christopher's observation that, given the likely volume of v6 traffic, you would not have a v6 load worth balancing?
My point was that the 'loadbalancers' do so much more than share load, and I don't want to lose this functionality. But to answer your question, the market isn't providing us with enough - or rather *any* interest, and this is what matters. If we reach the point where people can't buy widgets from us until we support IPv6, or that people would rather buy widgets from someone else because they support it, then we have to move. I don't know if there can be other financial incentives for us - if we can buy IPv6 connectivity very cheaply - which helps us squeeze those margins even more of course, then similarly we have to move. Quickly. -a
On Fri, 5 Aug 2005, Andy Davidson wrote:
Randy Bush wrote:
Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries. could you comment on christopher's observation that, given the likely volume of v6 traffic, you would not have a v6 load worth balancing?
My point was that the 'loadbalancers' do so much more than share load, and I don't want to lose this functionality.
Sure, and the things you pointed out you yourself pointed out could be done with mod_proxy on apache, provided the load wasn't TOO high...
But to answer your question, the market isn't providing us with enough - or rather *any* interest, and this is what matters. If we reach the point where people can't buy widgets from us until we support IPv6, or that people would rather buy widgets from someone else because they support it, then we have to move.
This arguement we (mci/uunet) used/use as well: "not enough demand to do any v6, put at bottom of list"... (until recently atleast it still flew as an answer) How would you know if you had demand? how would you know if people who had dualstack systems were trying to get AAAA and failing? Seriously, I'm just curious here... this is akin to the 'if a tree fell inn the forest would it make noise' problem.
I don't know if there can be other financial incentives for us - if we can buy IPv6 connectivity very cheaply - which helps us squeeze those margins even more of course, then similarly we have to move. Quickly.
v6 is free in most places today, sprint/verio/uu (someone else I'm forgetting, sorry!) in the US atleast have v6 connectivity for 'free' (provided you have a v4 link), is 'free' cheap enough? :)
Christopher L. Morrow wrote:
This arguement we (mci/uunet) used/use as well: "not enough demand to do any v6, put at bottom of list"... (until recently atleast it still flew as an answer) How would you know if you had demand? how would you know if people who had dualstack systems were trying to get AAAA and failing?
Seriously, I'm just curious here... this is akin to the 'if a tree fell inn the forest would it make noise' problem.
Run statistics off some selected recursive resolvers? Filter out spammers and other abuse first to make them more accurate. Pete
On Sat, 6 Aug 2005, Petri Helenius wrote:
Christopher L. Morrow wrote:
This arguement we (mci/uunet) used/use as well: "not enough demand to do any v6, put at bottom of list"... (until recently atleast it still flew as an answer) How would you know if you had demand? how would you know if people who had dualstack systems were trying to get AAAA and failing?
Run statistics off some selected recursive resolvers? Filter out spammers and other abuse first to make them more accurate.
Ok, perhaps off your auth boxes would be better as you likely aren't getting copies of the log from my (or anyone else's) recursive servers. anyone atleast doing this? -Chris
On 6-aug-2005, at 23:58, Christopher L. Morrow wrote:
how would you know if people who had dualstack systems were trying to get AAAA and failing?
Run statistics off some selected recursive resolvers? Filter out spammers and other abuse first to make them more accurate.
Ok, perhaps off your auth boxes would be better as you likely aren't getting copies of the log from my (or anyone else's) recursive servers.
anyone atleast doing this?
I ran a web bug for a reasonably popular generic Dutch site for a while, and I discovered that around 0.16% of all requests (that's about 1 in 666) happened over IPv6. Counting AAAA requests isn't very reliable, as some software performs these requests even if the system has no IPv6 connectivity. I believe Firefox does this unless IPv6 support is turned off. (It's turned on by default on nix and Win, off on Mac.)
On Fri, 5 Aug 2005, Andy Davidson wrote:
Christopher L. Morrow wrote:
will the v6 access really be enough to require LB's? or are they there for other reasons (global lb for content close to customers, regionalized content) perhaps reasons which would matter 'less' in an initial v6 world where you were getting the lb's fixed by their vendor? (or finding a vendor that supports v6 lb?)
I am a keyboard jockey for an international online retailer; I picked our loadbalancer solution[0] because of the things it did other than balancing load per se, including cacheing, tcp and ssl session offloading, and content compression. Yes, you could do much of this with apache/mod_proxy but not 'as well'.
Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries.
LVS which rather a lot of people use for load balancing supports ipv6 and has since 2002 PLB pure load balancer (*BSD) supports ipv6. Since Redhat Enterprise Server currently meets all of our layer-3 load balancing needs we haven't evaluated other commercial load balancers in about a year.
[0] Redline Networks E|X, now owned by Juniper of Borg.
-a
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Joel Jaeggli wrote:
LVS which rather a lot of people use for load balancing supports ipv6 and has since 2002
This is what I binned in favour of Redline. I don't know whether you're balancing HTTP or something else, but if you are balancing web traffic, then you may get much better performance using a reverse proxy (taking advantage of keepalives in your httpd and proxy). We did. -a
On Fri, 5 Aug 2005, Andy Davidson wrote:
Christopher L. Morrow wrote:
will the v6 access really be enough to require LB's? or are they there for other reasons (global lb for content close to customers, regionalized content) perhaps reasons which would matter 'less' in an initial v6 world where you were getting the lb's fixed by their vendor? (or finding a vendor that supports v6 lb?)
---snip lb chatter---
Until such devices support IPv6, to reiterate Steve's point, it's not an option to consider approaching connectivity suppliers with IPv6 enquiries.
One hopes for your sake you are poking the vendor for v6 support, poking hard and often. If the talk of a complete v6 transition for Yahoo-BB in japan goes over, and they have 'crappy' or 'no' v4 to the users there's some large number of millions of users disappearing from the v4 network, hurry up :)
[0] Redline Networks E|X, now owned by Juniper of Borg.
-a
On 8/4/05 6:49 PM, "Steve Feldman" <feldman@twincreeks.net> wrote:
I meant to ask this at a nanog or this IETF... why don't some of the larger content providers (google, msn, yahoo, to name 3 examples) put AAAA records in for their maint content pieces? why don't they get v6 connectivity from their providers (that offer such services) ? There are starting to be more and more folks with v6 connectivity... it'd be interesting as a way to drive usage on v6, eh?
(I work for a not-quite-as-large content player. These are my own opinions, but this is what I'd tell my empolyer if they asked.)
- We can't get provider-independent IPv6 space (without pretending to be a service provider.)
- None of our transit providers appear to provide IPv6 transit. Or if they do, they keep it pretty quiet. (Does UUNET?)
- Most of our content is delivered via load balancer hardware that would also need to support IPv6. Last time I checked, it didn't.
- There are (perceived to be) more important things to spend our limited resources on.
Steve
Why should content providers be at all interested in driving v6 usage? They are interested in meeting demand, innovating, collecting ad revenue, etc. The ROI to the given content provider is what? There ARE more important things to spend one's limited resources on. - Dan
On Fri, 5 Aug 2005, Daniel Golding wrote:
On 8/4/05 6:49 PM, "Steve Feldman" <feldman@twincreeks.net> wrote:
I meant to ask this at a nanog or this IETF... why don't some of the
- There are (perceived to be) more important things to spend our limited resources on.
Why should content providers be at all interested in driving v6 usage? They are interested in meeting demand, innovating, collecting ad revenue, etc. The ROI to the given content provider is what? There ARE more important things to spend one's limited resources on.
Content providers will have to do something about v6 'soon' (ho wsoon is another matter I suppose) I was attempting to spur on some discussion (which this did) about v6 deployment. I was also suggesting that perhaps a sideline v6 access to some larger providers would make other folks move forward, and would get vendors in to the right mood about v6 on their gear. 'checkbox' support is just not going to fly when the fan finally starts spinning and the darkmatter starts flying :(
On Thu, 4 Aug 2005, Stephen J. Wilcox wrote:
Hi David, I realise that but:
1. Softbank BB is not on my radar of likely /8 candidates (of course, geography may be the reason for that)
perhaps, remember that japan has +100m 'users' on them islands, eh? "we are planning a dsl network rollout to the home island of japan, expected subscriber base is 15M users conservatively" now I get a /8. simple, see? :)
2. We know cable companies, dsl providers and mobile companies can use this many IPs, but they generally seem to make use of NAT and IPv6. If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space.
Actually, I think it'd be GOOD if the v4 space got very scarce very fast... it'd make people stop putzing around with v6 amd mae it production for real. (perhaps even someone would think about how to multihome in v6? in a workable manner)
I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists..
So, makes you wonder: 1) comcast doesn't care about subscribers getting 'partial' connectivity due to acls/bogon-filters/blah 2) comcast fights this battle silently, with battle hardened network ninjas, silent killers of bogon filtering 3) the mythical bogon filtering 'problem' isn't really a problem? (sort of poking fun, mostly being serious...) -Chris
On 5-aug-2005, at 0:09, Christopher L. Morrow wrote:
2. We know cable companies, dsl providers and mobile companies can use this many IPs, but they generally seem to make use of NAT and IPv6. If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space.
Actually, I think it'd be GOOD if the v4 space got very scarce very fast... it'd make people stop putzing around with v6 amd mae it production for real. (perhaps even someone would think about how to multihome in v6? in a workable manner)
The first six months of this year nearly 100 million addresses were given out by the RIRs. (How many were returned I don't know.) With some 1100 - 1200 million lying around the IANA storage facility unused, this gives us some 5 years before we run out of _unused_ address space, if nothing changes. Even if there is significant growth, it's virtually impossible for those billion+ addresses to run out within 3 years. Five years is a long time, you can upgrade a lot of load balancers in such a period. You can upgrade a good number in three years, too.
In message <Pine.LNX.4.44.0508041931430.1697-100000@server2.tcw.telecomplete.ne t>, "Stephen J. Wilcox" writes:
2. We know cable companies, dsl providers and mobile companies can use this ma ny IPs, but they generally seem to make use of NAT and IPv6. If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space.
I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists..
When it comes to Comcast, I'm just an ordinary residential subscriber, but they don't use NAT for subscriber addresses as best I can tell. Certainly, I've never been given one, asked about one, etc. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Actually the cable modems and Dsl modems usually have a 10.x address they are used by the ISP's to access their internal firware. Also on traces that I have done on both cable and dsl the first hop is invariably a RFC1918 address. Steven M. Bellovin wrote:
In message <Pine.LNX.4.44.0508041931430.1697-100000@server2.tcw.telecomplete.ne t>, "Stephen J. Wilcox" writes:
2. We know cable companies, dsl providers and mobile companies can use this ma ny IPs, but they generally seem to make use of NAT and IPv6. If everyone in this category who could justify a /8 applied and received them we might be in real trouble with our IPv4 space.
I had said elsewhere this was unprecedented but was then pointed at 73.0.0.0/9, 73.128.0.0/10 which is Comcast assigned in April. I'm surprised none of these assignemtns have shown up on mailing lists..
When it comes to Comcast, I'm just an ordinary residential subscriber, but they don't use NAT for subscriber addresses as best I can tell. Certainly, I've never been given one, asked about one, etc.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
.
-- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/
I think i did not make myself clear. The corrections off-list are valid..:) However the modems are accessed by the providers using RFC1918 space and not public IP space. This is true it does not mean they are natting the users..however they are using large amounts of RFC1918 space to either save address space in general or save the costs associated with the additional address space they would consume if they did not use the RFC1918 space. William Warren wrote:
Actually the cable modems and Dsl modems usually have a 10.x address they are used by the ISP's to access their internal firware. Also on traces that I have done on both cable and dsl the first hop is invariably a RFC1918 address.
<snip> -- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/
On Sun, 7 Aug 2005, William Warren wrote:
I think i did not make myself clear. The corrections off-list are valid..:) However the modems are accessed by the providers using RFC1918 space and not public IP space. This is true it does not mean
and there was a mention at IETF by Alian of comcast (formerly of FT I thought?) that comcast was looking at an immediate ipv6 rollout: "because net 10 is not big enough"... 'immediate' on some scale not 'ten years out' (no timeframes mentioned, sorry)
they are natting the users..however they are using large amounts of RFC1918 space to either save address space in general or save the costs associated with the additional address space they would consume if they did not use the RFC1918 space.
William Warren wrote:
Actually the cable modems and Dsl modems usually have a 10.x address they are used by the ISP's to access their internal firware. Also on traces that I have done on both cable and dsl the first hop is invariably a RFC1918 address.
<snip>
-- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.
-- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician)
Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/
On 8/7/05 4:54 PM, "Christopher L. Morrow" <christopher.morrow@mci.com> wrote:
On Sun, 7 Aug 2005, William Warren wrote:
I think i did not make myself clear. The corrections off-list are valid..:) However the modems are accessed by the providers using RFC1918 space and not public IP space. This is true it does not mean
and there was a mention at IETF by Alian of comcast (formerly of FT I thought?) that comcast was looking at an immediate ipv6 rollout: "because net 10 is not big enough"... 'immediate' on some scale not 'ten years out' (no timeframes mentioned, sorry)
I suspect Comcast's mouth is bigger than its stomach, as it were. They have a few other things they may want to tackle before rolling out v6. I don't see a Comcact v6 rollout positively impacting their reliability. - Dan
On Mon, 8 Aug 2005, Daniel Golding wrote:
On 8/7/05 4:54 PM, "Christopher L. Morrow" <christopher.morrow@mci.com> wrote:
On Sun, 7 Aug 2005, William Warren wrote:
I think i did not make myself clear. The corrections off-list are valid..:) However the modems are accessed by the providers using RFC1918 space and not public IP space. This is true it does not mean
and there was a mention at IETF by Alian of comcast (formerly of FT I thought?) that comcast was looking at an immediate ipv6 rollout: "because net 10 is not big enough"... 'immediate' on some scale not 'ten years out' (no timeframes mentioned, sorry)
I suspect Comcast's mouth is bigger than its stomach, as it were. They have a few other things they may want to tackle before rolling out v6. I don't see a Comcact v6 rollout positively impacting their reliability.
oh, you mean like how are they going to manage that device which is imbedded and doesn't know from v6 today? :) yea, I was just repeating a quote from the conference, nothing more. Funny though it was.
On Thu, 4 Aug 2005, David Conrad wrote:
If you can justify a /8, ARIN will allocate one to you (not that I speak for ARIN or anything, but that's how things work). Presumably Softbank BB justified the /8 APNIC allocated to them.
I don't know about APNIC, but ARIN's rules are generally structured to make justification of a /8 all but impossible. I suspect this is actually a typo or misreading of some sort. jms
On Thu, 4 Aug 2005, Justin M. Streiner wrote:
On Thu, 4 Aug 2005, David Conrad wrote:
If you can justify a /8, ARIN will allocate one to you (not that I speak for ARIN or anything, but that's how things work). Presumably Softbank BB justified the /8 APNIC allocated to them.
I don't know about APNIC, but ARIN's rules are generally structured to make justification of a /8 all but impossible. I suspect this is actually a typo or misreading of some sort.
The business of the rir's is providing ip addresses to their members. if withholding the remaining address space became more important than supporting the needs of the community of interest, then they've obviously failed their membership.
jms
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Hi,
If you can justify a /8, ARIN will allocate one to you (not that I speak for ARIN or anything, but that's how things work). Presumably Softbank BB justified the /8 APNIC allocated to them. I don't know about APNIC, but ARIN's rules are generally structured to make justification of a /8 all but impossible.
Justin: I would be interested in understanding why you feel this to be the case (not that I'm disagreeing with you, rather I'm actually curious). In theory, justification for a /8 is no more impossible than justification for a /19. Of course, justifying a /8 will require proportionally more information than for a /19, but I wouldn't imagine this would be impossible.
I suspect this is actually a typo or misreading of some sort.
I don't believe it is.
The business of the rir's is providing ip addresses to their members. if withholding the remaining address space became more important than supporting the needs of the community of interest, then they've obviously failed their membership.
Yes. More to the point, given ARIN's policies, like the other RIRs, are defined in open public policy meetings, it would indicate either the community of interest desired the policies to be that way or the ARIN staff had run amok. I do not believe either to be the case. Rgds, -drc
The business of the rir's is providing ip addresses to their members. if withholding the remaining address space became more important than supporting the needs of the community of interest, then they've obviously failed their membership.
not for long, as their membership elects/appoints/... them randy
On Thu, 4 Aug 2005, Stephen J. Wilcox wrote:
i thought the decade of giving class A's to large corporates had long since passed.. we've got some major network rollout coming up, i need an extra 16 million IPs, so can i get one?
wtf?
Yahoo BB is one of the largest ISPs in Japan, I saw a slide where it was said they had 11 million subscribers. -- Mikael Abrahamsson email: swmike@swm.pp.se
participants (32)
-
abuse＠cabal.org.uk -
Andy Davidson -
Bill Woodcock -
bmanning＠vacation.karoshi.com -
Bruce Campbell -
Christopher L. Morrow -
Daniel Golding -
Daniel Roesen -
David Conrad -
Elmar K. Bins -
Florian Weimer -
Iljitsch van Beijnum -
Jay R. Ashworth -
Joe Abley -
Joel Jaeggli -
Joseph S D Yao -
Justin M. Streiner -
kawamura seiichi -
Michael Loftis -
Mikael Abrahamsson -
Paul Vixie -
Petri Helenius -
Randy Bush -
Roy Badami -
Sabri Berisha -
Simon Lyall -
Stephen J. Wilcox -
Steve Feldman -
Steven M. Bellovin -
Todd Vierling -
Valdis.Kletnieks＠vt.edu -
William Warren