There has been much talk about IPv6 lately, and for good reason. Whatever your opinion on whether IPv6 is a good solution to IPv4 address exhaustion, it's the only solution we have. Yet deployment, at least in North America, has been ridiculously slow. I have just been informed by a sales rep for AS852 that they are not deploying IPv4 until 2012. 2012? Really? I've heard statements that AS701 has deployed IPv6 on their network but I've yet to see any evidence of that in my area of Canada. Apparently they "forgot" Canada when they did it. Now I'm informed, unofficially, that they might maybe have it deployed, if I'm lucky, some time before the end of 2011. I think the above two points illustrate precisely why so many networks in North America simply cannot deploy IPv6 whether they want to or not. We simply cannot obtain IPv6 transit from our upstreams. It's just not available. And the old line about "vote with your money" doesn't work when you have limited choices.
On 11 mei 2011, at 16:39, William Astle wrote:
I think the above two points illustrate precisely why so many networks in North America simply cannot deploy IPv6 whether they want to or not. We simply cannot obtain IPv6 transit from our upstreams. It's just not available. And the old line about "vote with your money" doesn't work when you have limited choices.
Apparently the need for IPv6 isn't yet high enough to consider adding a transit provider. I've seen enough press releases from NTT and HE to know there's at least two that can do this out there.
On 05/11/2011 09:50 AM, Iljitsch van Beijnum wrote:
On 11 mei 2011, at 16:39, William Astle wrote:
I think the above two points illustrate precisely why so many networks in North America simply cannot deploy IPv6 whether they want to or not. We simply cannot obtain IPv6 transit from our upstreams. It's just not available. And the old line about "vote with your money" doesn't work when you have limited choices.
Apparently the need for IPv6 isn't yet high enough to consider adding a transit provider. I've seen enough press releases from NTT and HE to know there's at least two that can do this out there.
Funny, I was just involved in a discussion on IPv6 in Canada yesterday, and this link came up from multiple people: http://bgpmon.net/blog/?p=382 . There's also http://www.vyncke.org/ipv6status/detailed.php?country=ca&type=ISP , but I've seen some indications that there may be some inaccuracies (Allstream announcing 2001:04c8::/33, for instance). Jima
Apparently the need for IPv6 isn't yet high enough to consider adding
a
transit provider. I've seen enough press releases from NTT and HE to know there's at least two that can do this out there.
I believe the major holdup at this point is lack of v6 eyeballs. End user CPE, particularly DSL CPE, has been lagging in v6 capability. As for v6 upstreams, I have native v6 with both InterNAP (may not be available at ALL POPs yet) and HE. Savvis has yet to deploy it in the US at the POP pertinent to our operatons. The big push for v6 eyeballs at the current time are the mobile operators. We are seeing activity that would indicate there are mobile devices out there that are native v6 at this time. Content providers who have a lot of mobile clients might find they have more native v6 eyeballs than they think they have. A couple of things you can do to check. First of all look for requests to your DNS servers for AAAA records and note where those are coming from. That doesn't prove a lot but it gives some indication of who might have v6 someplace in their network. If you are seeing a significant number of these, the next thing I would do is get a dns server on your network working with v6 and get that IP address in whois even if all you are serving is v4 A records. Then note who is arriving over v6 asking for AAAA records. Those are the best candidates for enabling v6 services. Note which services those are asking for, pick one, and if you have gear capable of it (say, for example, a load balancer), configure a v6 VIP for that service balancing to v4 servers behind it. Place the AAAA record for this service in the zone handed out via v6 AAAA requests (ONLY!) and watch the service VIP and see if clients are connecting. So at this point you are handing out AAAA records for a v6 service but ONLY for DNS requests that arrive via IPv6 asking for it. Any requests arriving via v4 asking for an AAAA record would get the NOERROR response and an A record for the resource (client might have IPv6 internally but doesn't have v6 all the way to the Internet or their Internet coverage might be "spotty" and doesn't include you coughCogentcough).
On 11 mei 2011, at 19:01, George Bonser wrote:
A couple of things you can do to check. First of all look for requests to your DNS servers for AAAA records and note where those are coming from.
Firefox has for a long time done both A and AAAA lookups even if the system doesn't have IPv6. I believe MacOS does this too, now. Don't know about other apps/OSes, but for sure you'll see tons of AAAA lookups from people who have no IPv6 connectivity.
Then note who is arriving over v6 asking for AAAA records. Those are the best candidates for enabling v6 services.
Now you're counting DNS servers. Because the provisioning of IPv6 DNS addresses has been such a mess and still is problematic, many dual stack systems do this over IPv4. And the DNS servers they talk to may be IPv4-only, or IPv4-only users may talk to dual stack DNS servers. In my opinion, looking at this kind of stuff in order to draw conclusions about what you should do is a waste of time. It just means more work for everyone and it doesn't fix any of the broken stuff that's out there. If the results of world IPv6 day are as we expect and only 0.1 - 0.2 % or less of all people have problems, I think the best way forward would be to have a second world IPv6 day where we again enable IPv6 industry-wide but this time we don't turn it off again.
On May 11, 2011, at 1:12 PM, Iljitsch van Beijnum wrote:
On 11 mei 2011, at 19:01, George Bonser wrote:
A couple of things you can do to check. First of all look for requests to your DNS servers for AAAA records and note where those are coming from.
Firefox has for a long time done both A and AAAA lookups even if the system doesn't have IPv6. I believe MacOS does this too, now. Don't know about other apps/OSes, but for sure you'll see tons of AAAA lookups from people who have no IPv6 connectivity.
It is still a way to measure it, even if it's not that accurate.
Then note who is arriving over v6 asking for AAAA records. Those are the best candidates for enabling v6 services.
Now you're counting DNS servers. Because the provisioning of IPv6 DNS addresses has been such a mess and still is problematic, many dual stack systems do this over IPv4. And the DNS servers they talk to may be IPv4-only, or IPv4-only users may talk to dual stack DNS servers.
In my opinion, looking at this kind of stuff in order to draw conclusions about what you should do is a waste of time. It just means more work for everyone and it doesn't fix any of the broken stuff that's out there.
If the results of world IPv6 day are as we expect and only 0.1 - 0.2 % or less of all people have problems, I think the best way forward would be to have a second world IPv6 day where we again enable IPv6 industry-wide but this time we don't turn it off again.
I'd like to see a repeat but with a week timescale. If you parse carefully, if all the $major sites are broken in the same way at the same time, it's easier to justify leaving it broken. (eg: if Google, Yahoo and Bing all do IPv6 at once, neither has to worry about losing market share to the other due to misbehaving ipv6. That's how I read igor's email about the 182k users, even if I still think we would be served with a longer test). The most interesting data for me is looking at the sites that have 'majorly' broken IPv6 dns. I count 600+ sites that are returning weird things like ::1 or ::ffff: addresses. My favorites are the .gov site on the list and the city of albany. Here's a pointer to the list: http://puck.nether.net/~jared/aaaa/very-broken-dns.txt - Jared
* Iljitsch van Beijnum
Firefox has for a long time done both A and AAAA lookups even if the system doesn't have IPv6.
They fixed that in version 4.0, by calling getaddrinfo() with the AI_ADDRCONFIG flag (like most other browsers do). https://bugzilla.mozilla.org/show_bug.cgi?id=614526 -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
Now you're counting DNS servers. Because the provisioning of IPv6 DNS addresses has been such a mess and still is problematic, many dual stack systems do this over IPv4. And the DNS servers they talk to may be IPv4-only, or IPv4-only users may talk to dual stack DNS servers.
Which is why I suggested trying it on ONE service and watching it closely. What I have done is selected a "best candidate" for a test. I am not implying that "this is guaranteed to work".
If the results of world IPv6 day are as we expect and only 0.1 - 0.2 % or less of all people have problems, I think the best way forward would be to have a second world IPv6 day where we again enable IPv6 industry- wide but this time we don't turn it off again.
0.1% of users is a HUGE number if you have 1,000,000 subscribers. Are you prepared to field 1,000 helpdesk calls or lose 1,000 customers? Now imagine 100,000,000 subscribers. Are you ready for 10,000 support calls or the loss of 10,000 paying customers? It isn't something you just throw out there on a whim and tell people to like it or lump it if there are potentially a lot of people involved.
On 11 mei 2011, at 19:32, George Bonser wrote:
If the results of world IPv6 day are as we expect and only 0.1 - 0.2 % or less of all people have problems, I think the best way forward would be to have a second world IPv6 day where we again enable IPv6 industry- wide but this time we don't turn it off again.
0.1% of users is a HUGE number if you have 1,000,000 subscribers. Are you prepared to field 1,000 helpdesk calls or lose 1,000 customers?
Apparently "we" are, at least for the former, otherwise there wouldn't be an IPv6 day.
It isn't something you just throw out there on a whim and tell people to like it or lump it if there are potentially a lot of people involved.
So what's the alternative? Never change anything? Remember, this is al extremely trivial stuff: most things won't even completely stop working. And a few mouseclicks (yes, you have to know which ones so the helpdesks better start figuring that out) and you're back to normal. Compare this to turning off analog TV transmitters that have been running for decades where people have to buy converter boxes and sometimes even install antennas on their roof to keep using the service.
So what's the alternative? Never change anything?
Of course not. But the best course forward is going to be different for different folks. What might work best for me might not (probably WILL not) work best for everyone else. One has to look at their situation and plan the best path for their business with their architecture and the resources they have available to them. I suggested one option but that might not work for others. Others might see a strict white listing, or maybe some combination of the two. But there is so much brokenness out there right now that I would hesitate to trust an AAAA request that arrives over v4 when there is a v6 name server available.
Remember, this is al extremely trivial stuff: most things won't even completely stop working. And a few mouseclicks (yes, you have to know which ones so the helpdesks better start figuring that out) and you're back to normal. Compare this to turning off analog TV transmitters
that
have been running for decades where people have to buy converter boxes and sometimes even install antennas on their roof to keep using the service.
It depends. There are other things to take into account. If you increase the time it takes a mobile device to complete a transaction by only a couple of seconds, if you multiply those couple of seconds by all of the users in a large metro area, you end up with devices increased use of network resources (and increased battery drain on the devices themselves). Anything that can be done to speed transactions up and get those transmitters shut off as quickly as possible is a win. If you don't have a lot of mobile clients hitting your site, then maybe that isn't a problem. Every network has their own set of resources and their own set of challenges and all of that has to fit within the network architecture they have deployed and their business model. Basically, there is no "magic bullet".
On 5/11/11 11:39 AM, George Bonser wrote:
It depends. There are other things to take into account. If you increase the time it takes a mobile device to complete a transaction by only a couple of seconds, if you multiply those couple of seconds by all of the users in a large metro area, you end up with devices increased use of network resources (and increased battery drain on the devices themselves). Anything that can be done to speed transactions up and get those transmitters shut off as quickly as possible is a win. If you don't have a lot of mobile clients hitting your site, then maybe that isn't a problem. Every network has their own set of resources and their own set of challenges and all of that has to fit within the network architecture they have deployed and their business model.
So in our environment reducing the load time on an application by a couple seconds nets out to several human lifetimes a month, so people count seconds and fractions of seconds like they're precious.
Basically, there is no "magic bullet".
indeed, it has to be applied systemically.
On Wed, May 11, 2011 at 11:39 AM, George Bonser <gbonser@seven.com> wrote:
There are other things to take into account. If you increase the time it takes a mobile device to complete a transaction by only a couple of seconds, if you multiply those couple of seconds by all of the users in a large metro area, you end up with devices increased use of network resources (and increased battery drain on the devices themselves). Anything that can be done to speed transactions up and get those transmitters shut off as quickly as possible is a win.
I agree that seconds sometimes matters, but the latency of a transaction doesn't have a linear relationship with radio or battery usage on a mobile device. Because of the timers involved in the state transitions (eg CELL_FACH -> CELL_DCH), a few seconds of extra latency often is inconsequential because there is a minimum duration for which the radio will stay awake anyways. Coalescing techniques like Android's setInexactRepeating method of the Alarm Manager also optimize radio access across multiple apps. And if I'm not mistaken, it's the transition to/from CELL_DCH which is the most expensive resource-wise for network operators, not the duration of keeping this state. The argument that IPv6-induced latency is going to affect mobile devices disproportionally doesn't seem especially compelling. -Nick
I agree that seconds sometimes matters, but the latency of a transaction doesn't have a linear relationship with radio or battery usage on a mobile device. Because of the timers involved in the state transitions (eg CELL_FACH -> CELL_DCH), a few seconds of extra latency often is inconsequential because there is a minimum duration for which the radio will stay awake anyways. Coalescing techniques like Android's setInexactRepeating method of the Alarm Manager also optimize radio access across multiple apps. Not every device out there is an android. Not every OS on every device handles connections the same way. Problems can compound if several different names must be looked up in order to get a complete page view. Are your images served from a different name? Do you have short TTLs that require names to be looked up frequently? Again, every network is going to have their own unique sets of issues. But until there are more eyeballs out there that are native v6, we aren't going to see a lot of movement.
On 11 mei 2011, at 20:39, George Bonser wrote:
So what's the alternative? Never change anything?
Of course not. But the best course forward is going to be different for different folks. What might work best for me might not (probably WILL not) work best for everyone else. One has to look at their situation and plan the best path for their business with their architecture and the resources they have available to them. I suggested one option but that might not work for others.
I find it strange that you approach this issue as one of the great questions of our time. If you don't want to enable IPv6 for your service at this time, then don't enable IPv6 for your service at this time. But you'll have to do it at some point, so doing it together with your competitors and/or big players seems like a good choice. Going through huge lengths to optimize for a problem that will only exist for a couple of years or so doesn't make sense to me. Also, all this special case logic has a nasty tendency to create all kinds of unexpected problems down the road. I'm sure that the people at Microsoft thought it was a swell idea to enable 6to4 by default. If they hadn't done that, they'd saved us all a lot of wasted time.
On Wed, 11 May 2011 10:32:54 PDT, George Bonser said:
0.1% of users is a HUGE number if you have 1,000,000 subscribers. Are you prepared to field 1,000 helpdesk calls or lose 1,000 customers? Now imagine 100,000,000 subscribers. Are you ready for 10,000 support calls or the loss of 10,000 paying customers?
Unless you have a captive audience for customers, you probably have a churn rate higher than 0.1% *anyhow*. And if you *do* have a captive audience, you won't lose customers. I would be interested in knowing if those people who say they can measure these 0.1% dips noticed anything due to the flooding and severe weather in the midwest and southeast US in the past few weeks.
On 05/11/2011 11:21, Valdis.Kletnieks@vt.edu wrote:
Unless you have a captive audience for customers, you probably have a churn rate higher than 0.1%*anyhow*.
This argument has already been refuted many times. Let's assume that you're right about the churn rate. The issue is enterprises not wanting to take affirmative steps to knock N% *more* customers off the site than whatever the current churn rate is by enabling IPv6. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
On 2011-May-11 16:39, William Astle wrote: [..]
I think the above two points illustrate precisely why so many networks in North America simply cannot deploy IPv6 whether they want to or not. We simply cannot obtain IPv6 transit from our upstreams. It's just not available. And the old line about "vote with your money" doesn't work when you have limited choices.
And you have just found out why transition technologies exist. They are called 'transition' for a reason: during the time that you cannot get (proper) native connectivity you can set up a tunnel to an entity that can provide you with proper IPv6. The same way you can also set up a IPv6-only transit session with a party that is located at an IX or such you are at. Might just be to cover the time till your current transits do support IPv6. It is just a way around the problem, it might not be nice but it can work and you can get ready, and might get enough insight on why not to use that organization any more who is causing all the feet to be dragged. Greets, Jeroen
I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed. These are also some of the more expensive providers on a per Mb basis. The one provider that was full IPv6 ready was Cogent. HE is also IPv6 (although we don't use them atm.) Sent from my “contract free” BlackBerry® smartphone on the WIND network. -----Original Message----- From: William Astle <lost@l-w.ca> Date: Wed, 11 May 2011 08:39:43 To: <nanog@nanog.org> Subject: IPv6 foot-dragging There has been much talk about IPv6 lately, and for good reason. Whatever your opinion on whether IPv6 is a good solution to IPv4 address exhaustion, it's the only solution we have. Yet deployment, at least in North America, has been ridiculously slow. I have just been informed by a sales rep for AS852 that they are not deploying IPv4 until 2012. 2012? Really? I've heard statements that AS701 has deployed IPv6 on their network but I've yet to see any evidence of that in my area of Canada. Apparently they "forgot" Canada when they did it. Now I'm informed, unofficially, that they might maybe have it deployed, if I'm lucky, some time before the end of 2011. I think the above two points illustrate precisely why so many networks in North America simply cannot deploy IPv6 whether they want to or not. We simply cannot obtain IPv6 transit from our upstreams. It's just not available. And the old line about "vote with your money" doesn't work when you have limited choices.
On 5/11/2011 11:03 AM, james@jamesstewartsmith.com wrote:
I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed. These are also some of the more expensive providers on a per Mb basis. The one provider that was full IPv6 ready was Cogent. HE is also IPv6 (although we don't use them atm.)
There are a number of networks in Canada that provide v6 transit both big and small. I have v6 transit from TATA, HE and Cogent out of Toronto. Many Canadian networks peer at Torix which also lists their v6 status. http://www.torix.net/peers.php ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/
On 2011-05-11 09:10, Mike Tancsa wrote:
On 5/11/2011 11:03 AM, james@jamesstewartsmith.com wrote:
I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed. These are also some of the more expensive providers on a per Mb basis. The one provider that was full IPv6 ready was Cogent. HE is also IPv6 (although we don't use them atm.)
There are a number of networks in Canada that provide v6 transit both big and small. I have v6 transit from TATA, HE and Cogent out of Toronto. Many Canadian networks peer at Torix which also lists their v6 status.
That highlights another problem I have. I have no presence in Toronto, nor do I have a business case (or resources) to build a presence there. The same applies to Vancouver which is the other popular city for such things. I do currently employ a tunnel from HE's tunnel broker and, as a result, I'm reasonably sure I can make IPv6 work when I have proper transit for it. However, it would be impolite at best to turn up any sort of production service over such a tunnel. Speaking from the perspective of a *small* network with very limited resources, adding a transit provider, even if one is available, is very expensive. Installation costs tend to dwarf any business gain, often running well into the 5 figure range. The same applies to switching transit providers. (Install costs are the same in either case.)
On 5/11/2011 11:03 AM, james@jamesstewartsmith.com wrote:
I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed. These are also some of the more expensive providers on a per Mb basis. The one provider that was full IPv6 ready was Cogent. HE is also IPv6 (although we don't use them atm.)
The same Cogent that asked me to pay extra for IPv6 and in return I get an incomplete IPv6 routing table?
On Thu, May 12, 2011 at 05:14, ML <ml@kenweb.org> wrote:
On 5/11/2011 11:03 AM, james@jamesstewartsmith.com wrote:
I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed. These are also some of the more expensive providers on a per Mb basis. The one provider that was full IPv6 ready was Cogent. HE is also IPv6 (although we don't use them atm.)
The same Cogent that asked me to pay extra for IPv6 and in return I get an incomplete IPv6 routing table?
Hi all, I can confirm this also, from HE I get 5411 routes on BGPv6, but only 4293 from Cogent... Although, they didn't charge me extra for v6 session... -- Ristic Sasa VeratNet ISP Serbia
On May 11, 2011, at 8:14 PM, ML wrote:
On 5/11/2011 11:03 AM, james@jamesstewartsmith.com wrote:
I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed. These are also some of the more expensive providers on a per Mb basis. The one provider that was full IPv6 ready was Cogent. HE is also IPv6 (although we don't use them atm.)
The same Cogent that asked me to pay extra for IPv6 and in return I get an incomplete IPv6 routing table?
We will happily provide you with a more complete IPv6 routing table, though we do, admittedly lack routes from Cogent and a couple of other players that are having difficulty realizing that IPv6 peering is somewhat different from IPv4. Owen DeLong Hurricane Electric
I can confirm full IPV6 connectivity from HE. -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Thursday, May 12, 2011 4:07 AM To: ml@kenweb.org Cc: nanog@nanog.org Subject: Re: IPv6 foot-dragging On May 11, 2011, at 8:14 PM, ML wrote:
On 5/11/2011 11:03 AM, james@jamesstewartsmith.com wrote:
I have had similar problems with our providers, and these are tier 1 companies that should have already been full deployed. These are also some of the more expensive providers on a per Mb basis. The one provider that was full IPv6 ready was Cogent. HE is also IPv6 (although we don't use them atm.)
The same Cogent that asked me to pay extra for IPv6 and in return I get an incomplete IPv6 routing table?
We will happily provide you with a more complete IPv6 routing table, though we do, admittedly lack routes from Cogent and a couple of other players that are having difficulty realizing that IPv6 peering is somewhat different from IPv4. Owen DeLong Hurricane Electric
Bernhard Schmidt <berni@birkenwald.de> wrote on 05/12/2011 06:27:38 AM:
Anthony Francis - Handy Networks LLC <anthony@handynetworks.com> wrote:
I can confirm full IPV6 connectivity from HE.
How can you confirm that when HE just admitted to be lacking IPv6 routes from Cogent and a couple of other players?
Anyone know roughly the current default-free routing table size for IPv6? Or, who holds the record for the largest IPv6 routing table at this point? Joe
On 2011-May-12 15:14, Joe Loiacono wrote:
Bernhard Schmidt <berni@birkenwald.de> wrote on 05/12/2011 06:27:38 AM:
Anthony Francis - Handy Networks LLC <anthony@handynetworks.com> wrote:
I can confirm full IPV6 connectivity from HE.
How can you confirm that when HE just admitted to be lacking IPv6 routes from Cogent and a couple of other players?
Anyone know roughly the current default-free routing table size for IPv6?
http://www.sixxs.net/tools/grh/status/ 3668 good/required prefixes Minimum of 271 prefixes (-3397) Average of 5322 prefixes (+1654) Maximum of 5917 prefixes (+2249) As you can see, some folks seem to carry HALF of the table EXTRA than they need.... let alone that poor ISP which is carrying almost 2/3s more, I don't have time to check into it, but I wonder how much junk is in there....
Or, who holds the record for the largest IPv6 routing table at this point?
Having more routes does not mean that the routes are useful... far from actually... Greets, Jeroen
On Thu, 12 May 2011, Jeroen Massar wrote:
As you can see, some folks seem to carry HALF of the table EXTRA than they need.... let alone that poor ISP which is carrying almost 2/3s more, I don't have time to check into it, but I wonder how much junk is in there....
A lot. I see /48 breakouts from /32 PA blocks for instance, announced by a customer AS of the PA holder AS. -- Mikael Abrahamsson email: swmike@swm.pp.se
A lot. I see /48 breakouts from /32 PA blocks for instance, announced by a customer AS of the PA holder AS.
-- Mikael Abrahamsson email: swmike@swm.pp.se
Which is kinda sad. If those customer AS are multihomed or plan to be multihomed, they can get their own allocation out of PI space. If they are not multihomed outside of the provider AS, there is no need for the provider to "leak" that /48 out of their AS to their peers.
George, On Thu, May 12, 2011 at 11:41 AM, George Bonser <gbonser@seven.com> wrote:
A lot. I see /48 breakouts from /32 PA blocks for instance, announced by a customer AS of the PA holder AS.
-- Mikael Abrahamsson email: swmike@swm.pp.se
Which is kinda sad.
It's reality.
If those customer AS are multihomed or plan to be multihomed, they can get their own allocation out of PI space. If they are not multihomed outside of the provider AS, there is no need for the provider to "leak" that /48 out of their AS to their peers.
In the RIPE region, being multihomed or planning to be it is not a sufficient condition for getting a PI prefix. And even if it was, the hit on DFZ is the same as from getting allocation from LIR. Even if they get their own /32, the hit would be the same (modulo individual FIB/RIB implementations). Consequently, there's work in progress to modernize RIPE IPv6 address policy. http://ripe62.ripe.net/presentations/148-wg.pdf p. 19 and forward. Cheers, Martin
In the RIPE region, being multihomed or planning to be it is not a sufficient condition for getting a PI prefix. And even if it was, the hit on DFZ is the same as from getting allocation from LIR. Even if they get their own /32, the hit would be the same (modulo individual FIB/RIB implementations). Consequently, there's work in progress to modernize RIPE IPv6 address policy. http://ripe62.ripe.net/presentations/148-wg.pdf p. 19 and forward.
Cheers, Martin
Martin, Possibly the hit might be the same, but possibly not. An organization that requires a second /48 from their upstream might get one that can't be aggregated with the previous one. It is my understanding that ARIN is attempting to structure their assignments so that if such growth occurs in PI space, it is likely (though not guaranteed) that the network will get a subsequent allocation that can be aggregated with the first. George
On May 12, 2011, at 3:49 PM, George Bonser wrote:
In the RIPE region, being multihomed or planning to be it is not a sufficient condition for getting a PI prefix. And even if it was, the hit on DFZ is the same as from getting allocation from LIR. Even if they get their own /32, the hit would be the same (modulo individual FIB/RIB implementations). Consequently, there's work in progress to modernize RIPE IPv6 address policy. http://ripe62.ripe.net/presentations/148-wg.pdf p. 19 and forward.
Cheers, Martin
Martin,
Possibly the hit might be the same, but possibly not. An organization that requires a second /48 from their upstream might get one that can't be aggregated with the previous one. It is my understanding that ARIN is attempting to structure their assignments so that if such growth occurs in PI space, it is likely (though not guaranteed) that the network will get a subsequent allocation that can be aggregated with the first.
George
Policy dictates that they reserve at least to the /44 for /48 assignments. Owen
On Thu, May 12, 2011 at 5:49 PM, George Bonser <gbonser@seven.com> wrote:
Possibly the hit might be the same, but possibly not. An organization that requires a second /48 from their upstream might get one that can't be aggregated with the previous one. It is my understanding that ARIN
A very important distinction. The _immediate_ hit to the DFZ might be the same as obtaining PI V6 space, but the _long term_ hit to the DFZ might be much greater; particularly if the user starts obtaining multiple non-aggregable /48s from different sources, or obtains an additional PI allocation later, but keeps using the original /48. It is a heck of a lot better for network stability that any multi-homed user get a /32 PI, and find that they will never need more than a /48 of it, than it is to try to "conserve" address bits, and require the multi-homed user stick it out with a /48. With IPv6, bits for addressing networks are not scarce (like they were with IPv4), but more importantly, router FIB bits _are_ scarcer. With IPv4, we face the certainty of address bit assignment exhaustion. With IPv6, we face a greater risk of address bit _router_ assignment exhaustion. Because every IPv6 address has 4x as many bits as an IPv4 address. And a /48 prefix has consumes at least 2x as many bits as a /24 prefix. -- -JH
On Thu, May 12, 2011 at 8:39 PM, Jimmy Hess <mysidia@gmail.com> wrote:
A very important distinction. The _immediate_ hit to the DFZ might be the same as obtaining PI V6 space, but the _long term_ hit to the DFZ might be much greater;
The real issue is that there are many /48 announcements today which should be either: 1) not in the DFZ at all, but are because of a) accidental pollution/leaks b) intentional de-aggregation, which is very often inappropriate 2) should instead be PI allocations to organizations, not delegated PA space This will only get worse unless we task the RIRs with doing the only real job they have left in a post-v6-transition world: working to enable connectivity without unnecessary DFZ bloat. There is no longer a need for RIRs to say "no" to allocation requests on the basis that we will run out of (IPv6) addresses. The sole reason for technical barriers in the application/request process at all is to keep the DFZ in-check. Yet, our community still refuses to explicitly alter RIR policy such that controlling DFZ growth is an explicit component of the RIRs' mission. We can very easily choose to have one of two scenarios: 1) The bad situation with IPv4, where half the DFZ is accidental leaks or poorly-designed networks that are essentially on auto-pilot; yet small businesses and ISPs are not able to acquire PI space for use in BGP and must use PA blocks from their transit providers 2) An opposite situation, where the DFZ does not contain any de-aggregates, but contains many PI routes from organizations who have their PI space announced by their ISP for the purpose of avoiding re-numbering, not for multi-homing using their own BGP routers/ASN/etc. Getting to either one of these two extremes is very easy. Right now, we are heading for #1. If all technical barriers for acquiring IPv6 PI were removed, we would probably have #2. How do we find a medium between them, where there aren't ASNs originating 1000+ unnecessary de-aggregates out of their own carelessness and ineptitude, but also, there isn't a /32 (or /48) announced for every mom & pop ISP who themselves do not participate in BGP, or every corporate branch office who do not want to renumber when they change ISPs? This is how RIRs are failing us. Except that the RIRs really can't fail us, because they do what the members direct them to do through policy. If we don't task them to help the community do a better job at managing the IPv6 DFZ now, we may never be able to go back and fix it. The genie is out of the bottle with IPv4; but realistically, IPv6 is young enough that we have plenty of wiggle-room in terms of allocation policy, typical inter-domain route filters, and so on. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On 13 mei 2011, at 2:39, Jimmy Hess wrote:
if the user starts obtaining multiple non-aggregable /48s from different sources, or obtains an additional PI allocation later, but keeps using the original /48.
Simple: make a rule that you don't get more than one PI block, and if you want a bigger one you have to return the old one. Oh wait, people use PI because they want to avoid renumbering? It was never meant for that. Maybe a good incentive to ask for the right size block in the first place. The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless. And that all in case a /48 isn't big enough (which is ridiculously rare in and of itself) to save ONE entry in the global routing table. So by trying to conserve the table we make it impossible to protect our routing tables.
It is a heck of a lot better for network stability that any multi-homed user get a /32 PI,
No, that's completely ridiculous. It's like saying all flights should be flown with 747s just in case 10 football teams show up unexpectedly. That is, if a 747 could carry a million people (64k more than a small 16-seat plane). Yes, the IPv6 address space is big but by giving people who need more than 65000 subnets a /32 so they can have 4000000000 subnets is unbelievably wasteful for no other reason than laziness.
On Fri, May 13, 2011 at 12:56 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 13 mei 2011, at 2:39, Jimmy Hess wrote:
if the user starts obtaining multiple non-aggregable /48s from different sources, or obtains an additional PI allocation later, but keeps using the original /48.
Simple: make a rule that you don't get more than one PI block, and if you want a bigger one you have to return the old one. Oh wait, people use PI because they want to avoid renumbering? It was never meant for that. Maybe a good incentive to ask for the right size block in the first place.
The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless.
Well, that one particular "someone" should at most be announcing 16 /48s (their deaggregated /44). If they announce a million /48s, they're actively hijacking space from 64,000 other people, and should be dealt with in an appropriate manner as a hijacker. :/ People are conflating two different issues here. RIR policy is not, and never has been, structured to prevent or punish active, realtime hijacking of IP space. The *only* thing that will prevent that, in real-time are techniques like PGBGP or so-BGP. Not RIR policies. Now, RIR policies may provide guidelines on what policies you may use to configure your BGBGP or soBGP rules; but the enforcement and protection side is up to you as an ISP, not up to the RIR. I have always been, and will continue to be, adamantly opposed to the idea of the RIRs taking on the role of the "routing table" and "forwarding table" police. :( Matt (as a side note--in order to have your "million /48s" table explosion happen through *legitimate* holders of space deaggregating, it would require 64K individual choices to deaggregate in order to have that happen; we don't even have that many ASNs out there yet. I'm not losing sleep over that at this point.)
On 13 mei 2011, at 18:42, Matthew Petach wrote:
The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless.
If they announce a million /48s, they're actively hijacking space from 64,000 other people, and should be dealt with in an appropriate manner as a hijacker. :/
It would be mostly unused space. But that doesn't matter much, the point is that your prefix length filters can't stop this. If, on the other hand, the RIRs only give out /48s from one limited set of address space swaths and /44s from another, /32s from yet another and so on, then if there are 64k /48s that comes from say two /32s and three /33s for a total deaggregation risk of 224k prefixes. This is something your router may be able to handle.
The *only* thing that will prevent that, in real-time are techniques like PGBGP or so-BGP. Not RIR policies.
See above. All this BGP security stuff is still vaporware as of today. Hopefully that will change in the future but I'm not holding my breath for the benefits to kick in.
(as a side note--in order to have your "million /48s" table explosion happen through *legitimate* holders of space deaggregating, it would require 64K individual choices to deaggregate in order to have that happen; we don't even have that many ASNs out there yet. I'm not losing sleep over that at this point.)
If you boil it slowly enough the frog will sleep just fine. I participated in the IETF multi6/shim6 and IRTF RRG efforts for years but I have since come to the conclusion that routing table growth is not a real problem, because if it were people would be more willing to accept the downsides that come with the proposed solutions.
Jeroen Massar <jeroen@unfix.org> wrote on 05/12/2011 09:19:21 AM:
On 2011-May-12 15:14, Joe Loiacono wrote:
Anyone know roughly the current default-free routing table size for IPv6?
Awesome web-site. The world of IPv6 routing on one page.
3668 good/required prefixes Minimum of 271 prefixes (-3397) Average of 5322 prefixes (+1654)
Or, who holds the record for the largest IPv6 routing table at this
Is this saying that poor aggregation has crept in already (to the tune of 45%)? Given the RIR IPv6 allocation strategies, any estimate on the ultimate size of the DFR IPv6 table and how much memory will be required? point?
Having more routes does not mean that the routes are useful... far from actually...
Right. But isn't that dependent on peer's good aggregation and suppression of bogons? Joe
Joe Loiacono wrote:
Jeroen Massar <jeroen@unfix.org> wrote on 05/12/2011 09:19:21 AM:
On 2011-May-12 15:14, Joe Loiacono wrote:
Anyone know roughly the current default-free routing table size for IPv6? http://www.sixxs.net/tools/grh/status/
Awesome web-site. The world of IPv6 routing on one page.
That is a great overview. And really, if a conservative institution such as the *catholic church* jumped on the IPv6 bandwagon there is really NO excuse for other companies to drag their heels, for crying out loud. ;-) http://www.sixxs.net/tools/whois/?AS8978 Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Hi,
Bernhard Schmidt <berni@birkenwald.de> wrote on 05/12/2011 06:27:38 AM:
Anthony Francis - Handy Networks LLC <anthony@handynetworks.com> wrote:
I can confirm full IPV6 connectivity from HE.
How can you confirm that when HE just admitted to be lacking IPv6 routes from Cogent and a couple of other players?
Anyone know roughly the current default-free routing table size for IPv6?
grh.sixxs.net shows around 5600 prefixes for most participants. But it depends on filters as well, I run strict filters (no more than /35 in PA space) and have around 4300 prefixes.
Or, who holds the record for the largest IPv6 routing table at this point?
I don't think the absolute number of prefixes is a valid metric. There is too many more-specific junk with partial visibility floating around. Bernhard
Anthony Francis - Handy Networks LLC wrote:
I can confirm full IPV6 connectivity from HE.
I'm using the HE tunnel also and it works fine. But I have a bit of difficulty getting the right ip6tables (and the single iptables) rules to work so that my one server that tunnels ipv6 can serve as a gateway server. I used http://madduck.net/docs/ipv6/ as a guide. Using tcpdump I can see a ping from a server behind the gateway going to the gateway server and the gateway server sends it to the tunnel, but nothing's coming back. i.e.: behind gateway: # ping6 2620:0:2d0:200::10 PING 2620:0:2d0:200::10(2620:0:2d0:200::10) 56 data bytes ^C --- 2620:0:2d0:200::10 ping statistics --- 392 packets transmitted, 0 received, 100% packet loss, time 391484ms gateway: # tcpdump -t -n -s 512 -vv ip6 or proto ipv6 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 512 bytes IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:470:85cd:0:20c:6eff:fed2:1947 > 2620:0:2d0:200::10: [icmp6 sum ok] ICMP6, echo request, length 64, seq 317 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:470:85cd:0:20c:6eff:fed2:1947 > 2620:0:2d0:200::10: [icmp6 sum ok] ICMP6, echo request, length 64, seq 318 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:470:85cd:0:20c:6eff:fed2:1947 > 2620:0:2d0:200::10: [icmp6 sum ok] ICMP6, echo request, length 64, seq 319 Anything obvious I might have missed? Can post more specifics later if needed. Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
participants (26)
-
Anthony Francis - Handy Networks LLC -
Bernhard Schmidt -
Doug Barton -
George Bonser -
Iljitsch van Beijnum -
james＠jamesstewartsmith.com -
Jared Mauch -
Jeff Wheeler -
Jeroen Massar -
Jeroen van Aart -
Jima -
Jimmy Hess -
Joe Loiacono -
Joel Jaeggli -
Joel Maslak -
Martin Millnert -
Matthew Petach -
Mikael Abrahamsson -
Mike Tancsa -
ML -
nick hatch -
Owen DeLong -
Sasa Ristic -
Tore Anderson -
Valdis.Kletnieks＠vt.edu -
William Astle