Re: Definitive Guide to IPv6 adoption
On Mon, Oct 18, 2010 at 09:27:21PM -0700, George Bonser wrote: I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it. Encoding high-resolution geographic coordinates, for multiple bodies in the solar system.
RE: Definitive Guide to IPv6 adoption
-Original Message- From: Eugen Leitl Sent: Tuesday, October 19, 2010 1:18 AM To: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption On Mon, Oct 18, 2010 at 09:27:21PM -0700, George Bonser wrote: I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it. Encoding high-resolution geographic coordinates, for multiple bodies in the solar system. I was thinking more along the lines of dynamic IP assignment on server hosts and mapping client 64-bit GUIDs to ip addresses for directing traffic to the host with the client state information.
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 1:10 PM, Jack Bates wrote: On 10/18/2010 1:20 PM, sth...@nethelp.no wrote: I still haven't seen any good argument for why residential users need /48s. No, I don't think that makes all the address assignments the same size is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. +1 This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy. What if your customers don't want prefix privacy and prefer, instead, to have the option of accessing their resources remotely, setting up mobile-IP home gateways, and any of the other functions that come from static prefixes? Finally, no, /56 isn't a great idea for other reasons. Sure, it will meet today's needs, but, it ignores a future in which households aren't simple flat topologies, but, instead have multiple layers of routers dynamically determining hierarchies and building topologies to meet a variety of needs not yet addressable due to the current limitations of IPv4. This isn't pie in the sky science fiction. Most of the technology exists today and all that is left is the deployment of sufficient address resources to the consumer and some integration work at the vendor level. Owen
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 2:39 PM, Doug Barton wrote: On Mon, 18 Oct 2010, Owen DeLong wrote: I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking. Q:Why are /48s everywhere a good idea? A:Because it's the design! Q:Why are /48s everywhere in the design? A?Because it's a good idea! Which of course ignores the second half of my comment... This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place. Unless those problems become endemic and start reducing the lowest common denominator to which vendors feel they must implement. There are advantages to being able to use 16 bits to build various forms of hierarchical topology on a dynamic basis within a SOHO environment. If we reduce that to 8 bits, we will block innovations that are currently underway in this space. The model I've been advocating is for ISPs (who have enough space) to start off reserving a /48 per customer and then assigning the first /56 from it. If after real operational experience it turns out /48 is the right answer, you're all set. If /56 turns out to be sufficient, when you use up all of the first /56s you can start on the first /56 in the second /49, etc. Uh, yeah, why not just get your /32 (or whatever larger prefix you started with) expanded or get an additional prefix to put the additional customers into? Then, you're still set and you haven't had to block or reduce capabilities your customers should be able to accept. Owen
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 5:45 PM, Marshall Eubanks wrote: On Oct 18, 2010, at 8:16 PM, Robert E. Seastrom wrote: sth...@nethelp.no writes: I still haven't seen any good argument for why residential users need /48s. No, I don't think that makes all the address assignments the same size is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. If we were to give a /48 to every human on the face of the planet, we would use about .25 of the total available IPv6 address space. You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.9% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo! It makes a bigger difference if everyone starts using 6RD - to give out a /48 effectively requires a /16, and the number of /16s is by no means approximately infinite. That is why the AC chose to allow for a /56 per end-site in the transitional technology policy (6rd is a transitional technology) and why we call for them to be issued from a distinct prefix separate from native IPv6 deployments. In this way, 6rd can be deployed sooner rather than later, but, we have the ability to move forward to a cleaner native IPv6 deployment and deprecate 6rd when it is no longer needed. Owen
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 7:24 PM, Doug Barton wrote: On 10/18/2010 5:16 PM, Robert E. Seastrom wrote: sth...@nethelp.no writes: I still haven't seen any good argument for why residential users need /48s. No, I don't think that makes all the address assignments the same size is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. If we were to give a /48 to every human on the face of the planet, we would use about .25 of the total available IPv6 address space. I'm confused. The hand out /48s everywhere crowd keeps saying that we need to do that because we haven't yet anticipated everything that end users might want to do with a /48 on their CPE. On the wider issue of we don't yet understand everything that can be done with the space I think we're in agreement. However my conclusion is that therefore we should be careful to preserve the maximum flexibility possible. Right... Giving /48s to end users for native IPv6 deployments still preserves 99.9975% (or more) of the IPv6 space while not stifling innovation on the CPE side. Maximum flexibility is preserved on both sides of the ISP/customer boundary. Giving customers less doesn't really increase meaningful flexibility for the providers, it just keeps more address space on the shelf gathering dust. After we have some operational experience with IPv6 we will be in a position to make better decisions; but we have to GET operational experience first. Grousing about lack of adherence to holy writ in that deployment doesn't help anybody. Some of us actually have some operational experience with IPv6. As such, I'm not grousing about holy writ, I'm talking about real consequences of real actions in real world implementations. Owen
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 6:25 PM, David Conrad wrote: RS, On Oct 18, 2010, at 2:16 PM, Robert E. Seastrom wrote: If we were to give a /48 to every human on the face of the planet, we would use about .25 of the total available IPv6 address space. Sure. I once did the math that suggested that even if you multiplied the current IPv4 consumption rate by 1000 and applied that consumption rate to IPv6 /48s, the 1/8th of the IPv6 address space used for global unicast would last over 100 years. The problem is that allocation policy depends on who shows up at RIR meetings. Marshall has pointed out the (potential) implications of that policy with respect to 6rd. My math didn't take 6rd into account. Simply, there is no finite resource that people can't figure out a way to waste in an insane fashion. Since IPv6 is a finite resource, I personally think it makes sense for folks to be reasonably conservative in assignment to customers. Regards, -drc Agreed. /48 is reasonably conservative in native IPv6 deployments. 6rd cannot be done in a reasonably conservative fashion, so, we're kind of stuck with giving /24s to ISPs to give /56s to their customers and living with the consequences. Owen
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 10:53 PM, Jack Bates wrote: On 10/18/2010 7:16 PM, Robert E. Seastrom wrote: You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.9% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo! Thanks. Actually, I think people are following the RIR example. ARIN handed out a /32 as standard for an ISP, so a /32 is the framework even a medium sized ISP will use. No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger. Our routing/IP Numbering Plan: regional assignmentpop assignmentcustomer assignment /40 regional assignment supporting 256 regional assignments /44 for only 16 pop assignments? /48 to customer for only 16 customers per pop assignment? Or, better...If you're that large... Start with a /28 /36 regional assignment supporting 256 regional assignments /40 for 16 pops per region /48 for 256 customer end-sites per POP or, if you have larger POPs, start with a /24 and /32 regional assignment supporting 256 regional assignments /36 for 16 pops per region /48 for 4,096 customer end-sites per POP or, if you have larger regions and more POPs per region /28 regional assignment supporting 16 regions /36 for 256 pops per region /48 for 4,096 customer end-sites per POP Perhaps another view /40 regional assignment supporting 256 regional assignments /44 still for 16 pop assignments /56 to customer for 4096 customer assignments I'm sorry, but I just couldn't find a way to make /48 to customers work appropriately, and ARIN seems to think a /32 is fair, yet I have to design an IP assignment plan up front to make for more efficient routing. I actually expect a /42-/43 per pop, and /38 per region even in the /56 to customer model. ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space. Owen
Re: Definitive Guide to IPv6 adoption
George Bonser gbon...@seven.com writes: You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.9% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo! I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it. Which just reinforces the argument that we ought to give people /48s rather than /56es, /60s, or /64s even though those with a failure of imagination may not be able to figure out a reason anyone would need that much space. -r
RE: Definitive Guide to IPv6 adoption
Hi,
Another way of looking at it would be what would the world population need to
be in order to exhaust all of the space v6 based on /48s /56s or /64s per head
/ household - and is this population number ever going to happen in what time
conceivable time frame.
Another interesting calculation would be to divide the land mass area by that
population figure - let alone the habital area.
2 to 48 = 281,474,976,710,658 or 280K Billion separate /48s assignments.
(Current world population 6.7 Billion forecast 14 Billion in 2100)
World Landmass (Total All Areas): 148.94 million sq km
So Each Person at the point of IPv6 exhaustion will have 0.53 sq meters to
stand on while using all their IPv6 devices.
I think it is safe to say that the world will be facing other more significant
problems long long long before we get anywhere near having to worry about
running out of IPv6 space because we are assigning each individual a /48.
There are surely technical benefits from a routing perspective if all the end
user assignments are the same size - therefore should the technical
considerations here not override any argument about conservation of space
seeing as the above hopefully proves the fallacy of needing to conserve IPv6
address space
Ben
-Original Message-
From: Robert E. Seastrom [mailto:r...@seastrom.com]
Sent: 19 October 2010 11:53
To: George Bonser
Cc: nanog@nanog.org
Subject: Re: Definitive Guide to IPv6 adoption
George Bonser gbon...@seven.com writes:
You are to be commended for your leadership in conserving space. Our
children will surely be grateful that thanks to your efforts they have
99.9% of IPv6 space left to work with rather than the paltry
99.9975% that might have been their inheritance were it not for your
efforts. Bravo!
I have a feeling that IP addresses will now be used in ways that people
have not envisioned them being used before. Given a surplus of any
resource, people find creative ways of using it.
Which just reinforces the argument that we ought to give people /48s
rather than /56es, /60s, or /64s even though those with a failure of
imagination may not be able to figure out a reason anyone would need
that much space.
-r
--
BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal;
TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #00; FONT-SIZE: 10px; FONT-WEIGHT: bold;
TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold;
TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #00; FONT-SIZE: 10px; TEXT-DECORATION:
none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica,
sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal;
TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold;
TEXT-DECORATION: none}
Ben Butler
Director Tel: 0333 666 3332
Fax: 0333 666 3331
C2 Business Networking Ltd
The Paddock, London Road, Nantwich, Cheshire, CW5 7JL
http://www.c2internet.net/
Part of the Atlas Business Group of Companies plc
Registered in England: 07102986 Registered Address: Datum House, Electra Way,
Crewe CW1 6ZF Vat Registration No: 712 9503 48
This message is confidential and intended for the use only of the person to
whom it is addressed. If you are not the intended recipient you are strictly
prohibited from reading, disseminating, copying, printing, re-transmitting or
using this message or its contents in any way. Opinions, conclusions and other
information expressed in this message are not given or authorised by the
Company unless otherwise indicated by an authorised representative independent
of this message. The Company does not accept liability for any data corruption,
interception or amendment to any e-mail or the consequences thereof.Emails
addressed to individuals may not necessarily be read by that person unless they
are in the office.Calls to and from any of the Atlas Business Group of
Companies may be recorded for the purposes of training, monitoring of quality
and customer services.
Re: Definitive Guide to IPv6 adoption
On 10/19/10, Owen DeLong o...@delong.com wrote: On Oct 18, 2010, at 1:10 PM, Jack Bates wrote: On 10/18/2010 1:20 PM, sth...@nethelp.no wrote: I still haven't seen any good argument for why residential users need /48s. No, I don't think that makes all the address assignments the same size is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. +1 This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy. What if your customers don't want prefix privacy and prefer, instead, to have the option of accessing their resources remotely, setting up mobile-IP home gateways, and any of the other functions that come from static prefixes? Why does it have to be one or the other? Isn't it possible to hand out a static assignment so that users can access their resources remotely as well as handing out a rotating prefix that changes every so often so that users have 'some chance at prefix privacy.' Lee
RE: Definitive Guide to IPv6 adoption
Hi,
Maybe we should reserve the first couple of bits to serve as a planet
identifier, so that once we have colonized the heavens Star Trek Federation
style we can route to all of those Billions of life forms.
Routing convergence times shouldn’t be too much of an issue even with light
version 1 (while we wait for FTL transport mechanisms) as I suspect there wont
be too many interplanetary transit providers to have worry about in the routing
mesh.
But again in all seriousness - surely this is a problem for the distant future
(sadly and Stephen Hawking would agree about our species' need for colonization
to ensure survival) and in the meantime we just get on as quickly as possible
with getting IPv6 rolled out and adhering to standards of how we do it so we
don't create yet another inconsistent mess with everyone following different
standard best practices.
Ben
-Original Message-
From: Ben Butler [mailto:ben.but...@c2internet.net]
Sent: 19 October 2010 12:26
To: nanog@nanog.org
Subject: RE: Definitive Guide to IPv6 adoption
Hi,
Another way of looking at it would be what would the world population need to
be in order to exhaust all of the space v6 based on /48s /56s or /64s per head
/ household - and is this population number ever going to happen in what time
conceivable time frame.
Another interesting calculation would be to divide the land mass area by that
population figure - let alone the habital area.
2 to 48 = 281,474,976,710,658 or 280K Billion separate /48s assignments.
(Current world population 6.7 Billion forecast 14 Billion in 2100)
World Landmass (Total All Areas): 148.94 million sq km
So Each Person at the point of IPv6 exhaustion will have 0.53 sq meters to
stand on while using all their IPv6 devices.
I think it is safe to say that the world will be facing other more significant
problems long long long before we get anywhere near having to worry about
running out of IPv6 space because we are assigning each individual a /48.
There are surely technical benefits from a routing perspective if all the end
user assignments are the same size - therefore should the technical
considerations here not override any argument about conservation of space
seeing as the above hopefully proves the fallacy of needing to conserve IPv6
address space
Ben
-Original Message-
From: Robert E. Seastrom [mailto:r...@seastrom.com]
Sent: 19 October 2010 11:53
To: George Bonser
Cc: nanog@nanog.org
Subject: Re: Definitive Guide to IPv6 adoption
George Bonser gbon...@seven.com writes:
You are to be commended for your leadership in conserving space. Our
children will surely be grateful that thanks to your efforts they have
99.9% of IPv6 space left to work with rather than the paltry
99.9975% that might have been their inheritance were it not for your
efforts. Bravo!
I have a feeling that IP addresses will now be used in ways that people
have not envisioned them being used before. Given a surplus of any
resource, people find creative ways of using it.
Which just reinforces the argument that we ought to give people /48s
rather than /56es, /60s, or /64s even though those with a failure of
imagination may not be able to figure out a reason anyone would need
that much space.
-r
--
BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal;
TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #00; FONT-SIZE: 10px; FONT-WEIGHT: bold;
TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold;
TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #00; FONT-SIZE: 10px; TEXT-DECORATION:
none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica,
sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal;
TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold;
TEXT-DECORATION: none}
Ben Butler
Director Tel: 0333 666 3332
Fax: 0333 666 3331
C2 Business Networking Ltd
The Paddock, London Road, Nantwich, Cheshire, CW5 7JL
http://www.c2internet.net/
Part of the Atlas Business Group of Companies plc
Registered in England: 07102986 Registered Address: Datum House, Electra Way,
Crewe CW1 6ZF Vat Registration No: 712 9503 48
This message is confidential and intended for the use only of the person to
whom it is addressed. If you are not the intended recipient you are strictly
prohibited from reading, disseminating, copying, printing, re-transmitting or
using this message or its contents in any way. Opinions, conclusions and other
information expressed in this message are not given
Re: Definitive Guide to IPv6 adoption
On Tue, 19 Oct 2010, Owen DeLong wrote: There are advantages to being able to use 16 bits to build various forms of hierarchical topology on a dynamic basis within a SOHO environment. If we reduce that to 8 bits, we will block innovations that are currently underway in this space. Can you give us some examples of these innovations that are currently underway? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
Re: Definitive Guide to IPv6 adoption
On 18/10/10 19:24 -0700, Doug Barton wrote: On 10/18/2010 5:16 PM, Robert E. Seastrom wrote: sth...@nethelp.no writes: I still haven't seen any good argument for why residential users need /48s. No, I don't think that makes all the address assignments the same size is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. If we were to give a /48 to every human on the face of the planet, we would use about .25 of the total available IPv6 address space. I'm confused. The hand out /48s everywhere crowd keeps saying that we need to do that because we haven't yet anticipated everything that end users might want to do with a /48 on their CPE. On the wider issue of we don't yet understand everything that can be done with the space I think we're in agreement. However my conclusion is that therefore we should be careful to preserve the maximum flexibility possible. After we have some operational experience with IPv6 we will be in a position to make better decisions; but we have to GET operational experience first. Grousing about lack of adherence to holy writ in that deployment doesn't help anybody. I agree with you, but have come to a different conclusion. I would fall under the /48s crowd, except that I'm not really interested in an attempt to standardize /48 deployments. But I still feel strongly that a /48 assignment model for residential customers is right for our environment. With v4 assignments, we have a different philosophy. When we received our v4 assignments from ARIN, is was natural for us to take a conservative approach when handing out addresses... by default we assign one dynamic address to each customer and provide one or more static addresses for a nominal fee to customers, not because we want to make money from it, but because we want to be good stewards of those addresses. That's our 'fail safe' approach to v4 distribution (1 per customer). With v6, our 'fail safe' approach, without strong operational experience, is to assign larger blocks rather than smaller. A cycle in our staff in 5 or 10 years is likely to appreciate that decision, and we can't really justify a /56-rather-than-/48 decision based on address constraints. We really do have the addresses to support /48 deployments for the foreseeable future, and would expect future staff to request more addresses when they're needed. -- Dan White
Re: Definitive Guide to IPv6 adoption
On 10/19/2010 4:29 AM, Owen DeLong wrote: No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger. ME: I really need larger space ARIN: We don't see how you can justify it, and we hardly ever give larger than /32 THE END or, if you have larger POPs, start with a /24 and /32 regional assignment supporting 256 regional assignments /36 for 16 pops per region /48 for 4,096 customer end-sites per POP Ideal solution, but don't see it happening ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space. See above. You think I asked for a /32? While I'd probably desire a /24 for ease of routing and management, I'd only asked for a /31 and was turned down with the Very few will get more than a /32. Hey, perhaps I'm wrong. Perhaps I asked too early, even though I purposefully delayed asking. and from your other reply: Yep... Best not to argue with Jack... A much better strategy, IMHO, is to better serve his former customers. Good luck on that. My customers like my service and the lengths we go for them. Obviously, there are always those who are discontent, but we listen to what they want and need, and we make it happen. Feel free to come to rural Oklahoma and compete. The prefix rotation argument has been covered before, which is why I'd rather keep it to the original argument and probably shouldn't have mentioned it since it always creates a side topic. Jack
Re: Definitive Guide to IPv6 adoption
On 10/19/2010 6:24 AM, Dan White wrote: But I still feel strongly that a /48 assignment model for residential customers is right for our environment. Perfectly reasonable. If you've analyzed your situation and come to that conclusion who am I to argue? Please note, I'm NOT saying, You must use /56 for residential! I'm saying that reasonable minds can differ, and that trying to jam everyone into the /48 mold does more harm than good. Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/
RE: Definitive Guide to IPv6 adoption
-Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Monday, October 18, 2010 5:12 PM To: Franck Martin Cc: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption On 10/18/2010 3:51 PM, Franck Martin wrote: So they can't run their own services from home and have to request premium connectivity from you? Beside the IPv4 scarcity mentality we have the Telco mentality to fight... Happy days still ahead... Of course they can run their own services at home. How does renumber effect that (outside of poor v6 implementations at this late stage)? v6 is designed to support multiple prefixes and the ability to change from one prefix to another with limited disruption, especially if I give 24 hours to complete the transition. If servers and services can't handle this, I'd say they need to improve, or the customer will need a static allocation, which we may or may not charge for (depending on how automated we make it). A sane default of rotation is appropriate for us, though, and no amount of fighting by anyone will make the Telco think that google or others have the right to track their users. It's unfair for our users who block cookies, do due diligence to not be tracked, and then we throw them to the wolves with a constant trackable prefix. HS: Where customers = spammers? The only folks I have seen ask to do 'address rotation' have either been spammers or copyright monitoring services. I have never seen a request for 'address rotation' to protect a customer from Google. Wouldn't you just tell them not to use Google's services? The *typical* residential user doesn't know and probably doesn't care whether their prefix is dynamic or static. Dynamic allocation of address space was, in part, meant to help conserve space - if the prefix was only needed for a couple hours, it could in theory be released and reused... allowing more efficient utilization of space. Now though, with always-on connections and folks wanting to access their content remotely - it makes sense to statically allocate prefixes... and the availability of addresses in IPv6 gives us the room to do this. Jack (knew this would start an argument. *sigh*)
Re: Definitive Guide to IPv6 adoption
On Oct 19, 2010, at 4:25 AM, Ben Butler wrote:
Hi,
Another way of looking at it would be what would the world population need to
be in order to exhaust all of the space v6 based on /48s /56s or /64s per
head / household - and is this population number ever going to happen in what
time conceivable time frame.
Another interesting calculation would be to divide the land mass area by that
population figure - let alone the habital area.
2 to 48 = 281,474,976,710,658 or 280K Billion separate /48s assignments.
(Current world population 6.7 Billion forecast 14 Billion in 2100)
World Landmass (Total All Areas): 148.94 million sq km
So Each Person at the point of IPv6 exhaustion will have 0.53 sq meters to
stand on while using all their IPv6 devices.
I think it is safe to say that the world will be facing other more
significant problems long long long before we get anywhere near having to
worry about running out of IPv6 space because we are assigning each
individual a /48.
This does, of course, assume that the population remains earthbound beyond 2100.
I think that is not entirely likely.
There are surely technical benefits from a routing perspective if all the end
user assignments are the same size - therefore should the technical
considerations here not override any argument about conservation of space
seeing as the above hopefully proves the fallacy of needing to conserve IPv6
address space
Yes... The technical considerations should override silly efforts to keep more
than 99.99% of all IPv6 space in reserve
for some unprojected need since we have real projected needs for the 0.001% now.
Owen
Ben
-Original Message-
From: Robert E. Seastrom [mailto:r...@seastrom.com]
Sent: 19 October 2010 11:53
To: George Bonser
Cc: nanog@nanog.org
Subject: Re: Definitive Guide to IPv6 adoption
George Bonser gbon...@seven.com writes:
You are to be commended for your leadership in conserving space. Our
children will surely be grateful that thanks to your efforts they have
99.9% of IPv6 space left to work with rather than the paltry
99.9975% that might have been their inheritance were it not for your
efforts. Bravo!
I have a feeling that IP addresses will now be used in ways that people
have not envisioned them being used before. Given a surplus of any
resource, people find creative ways of using it.
Which just reinforces the argument that we ought to give people /48s
rather than /56es, /60s, or /64s even though those with a failure of
imagination may not be able to figure out a reason anyone would need
that much space.
-r
--
BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal;
TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #00; FONT-SIZE: 10px; FONT-WEIGHT: bold;
TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold;
TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #00; FONT-SIZE: 10px; TEXT-DECORATION:
none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica,
sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal;
TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial,
Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold;
TEXT-DECORATION: none}
Ben Butler
Director Tel: 0333 666 3332
Fax: 0333 666 3331
C2 Business Networking Ltd
The Paddock, London Road, Nantwich, Cheshire, CW5 7JL
http://www.c2internet.net/
Part of the Atlas Business Group of Companies plc
Registered in England: 07102986 Registered Address: Datum House, Electra Way,
Crewe CW1 6ZF Vat Registration No: 712 9503 48
This message is confidential and intended for the use only of the person to
whom it is addressed. If you are not the intended recipient you are strictly
prohibited from reading, disseminating, copying, printing, re-transmitting or
using this message or its contents in any way. Opinions, conclusions and
other information expressed in this message are not given or authorised by
the Company unless otherwise indicated by an authorised representative
independent of this message. The Company does not accept liability for any
data corruption, interception or amendment to any e-mail or the consequences
thereof.Emails addressed to individuals may not necessarily be read by that
person unless they are in the office.Calls to and from any of the Atlas
Business Group of Companies may be recorded for the purposes of training,
monitoring of quality and customer services.
Re: Definitive Guide to IPv6 adoption
On Oct 19, 2010, at 5:21 AM, Tony Finch wrote: On Tue, 19 Oct 2010, Owen DeLong wrote: There are advantages to being able to use 16 bits to build various forms of hierarchical topology on a dynamic basis within a SOHO environment. If we reduce that to 8 bits, we will block innovations that are currently underway in this space. Can you give us some examples of these innovations that are currently underway? I have, and, Tony Hain does a better job, but, here goes: Imagine any or all of the following possibilities: Sensor networks within appliances with the appliance acting as a router Each home entertainment center is a collection of networked components with a router fronting each center. Kids networks with different filtration and security policies from those used by the adults in the house. Guest wireless networks. Groceries coming with RFID tags that your refrigerator and cabinets can use to identify their contents. A web server embedded in your kitchen router that fronts these networks can be queried from your cell phone while you are at the store to find out what you are running low on in real time. I'm sure there are more, but, these are things that could be done relatively easily with existing technology. Owen
Re: Definitive Guide to IPv6 adoption
On 10/19/2010 11:53 AM, Schiller, Heather A (HeatherSkanks) wrote: HS: Where customers = spammers? The only folks I have seen ask to do 'address rotation' have either been spammers or copyright monitoring services. I have never seen a request for 'address rotation' to protect a customer from Google. Wouldn't you just tell them not to use Google's services? The *typical* residential user doesn't know and probably doesn't care whether their prefix is dynamic or static. The typical resident often doesn't know, but when asked, they do want privacy, and they don't want to be tracked by various databases for marketing or geoIP tracking. Some customers prefer static, but to date, the only reason customers have asked for static in v4 is because it was necessary. If v6 continues to support application and design for renumbering, such statics won't be necessary and I'll have even fewer requests. Dynamic allocation of address space was, in part, meant to help conserve space - if the prefix was only needed for a couple hours, it could in theory be released and reused... allowing more efficient utilization of space. Now though, with always-on connections and folks wanting to access their content remotely - it makes sense to statically allocate prefixes... and the availability of addresses in IPv6 gives us the room to do this. With the new capabilities of multiple prefixes and renumbering capabilities and the various methodologies which will be used to easily switch between providers (or balance traffic between multiple providers using multiple prefixes), rotating prefixes every 24 hours shouldn't be a big deal. The customer will still gain remote access to their content, while also remaining a moving target. Customer's care about privacy, even when they don't realize if they truly have it or not. M$ considered privacy extensions on by default to be a good thing. I'm just extending it to the prefix. You can change nic cards as easily as you change ISPs (easier out here, actually). As customers actually notice or care that they are using v6, I'm sure I'll have more static requests as well, which we'll probably automate. Jack
Re: Definitive Guide to IPv6 adoption
On Oct 19, 2010, at 7:09 AM, Jack Bates wrote: On 10/19/2010 4:29 AM, Owen DeLong wrote: No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger. ME: I really need larger space ARIN: We don't see how you can justify it, and we hardly ever give larger than /32 Did you send them a customer count exceeding about 25,000 customers and point out that you were giving /48s to each of them? If you did, they would not have had a leg to stand on. However, there has been a bit of a learning curve with ARIN staff and IPv6, so, there have been some errant denials. I'm working on policy to further expand their ability to approve larger allocations. Expect to see it posted in the next week or so. THE END or, if you have larger POPs, start with a /24 and /32 regional assignment supporting 256 regional assignments /36 for 16 pops per region /48 for 4,096 customer end-sites per POP Ideal solution, but don't see it happening Why not? ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space. See above. You think I asked for a /32? While I'd probably desire a /24 for ease of routing and management, I'd only asked for a /31 and was turned down with the Very few will get more than a /32. When did you ask? If it was more than 6 months ago, then, I would suggest asking again. If it was less than 6 months ago, can you send me any or all of the correspondence so I can address it with Leslie and try and get whatever training issues remain resolved? Hey, perhaps I'm wrong. Perhaps I asked too early, even though I purposefully delayed asking. If ARIN is incorrectly denying requests, I'll definitely work on getting that resolved. and from your other reply: Yep... Best not to argue with Jack... A much better strategy, IMHO, is to better serve his former customers. Good luck on that. My customers like my service and the lengths we go for them. Obviously, there are always those who are discontent, but we listen to what they want and need, and we make it happen. Feel free to come to rural Oklahoma and compete. The prefix rotation argument has been covered before, which is why I'd rather keep it to the original argument and probably shouldn't have mentioned it since it always creates a side topic. The beauty is that we don't have to come to rural OK to compete. We can just let them use whatever stingy amount of address space you provide to get a tunnel to us. Owen
Re: Definitive Guide to IPv6 adoption
On 10/19/2010 1:21 PM, Owen DeLong wrote: When did you ask? If it was more than 6 months ago, then, I would suggest asking again. If it was less than 6 months ago, can you send me any or all of the correspondence so I can address it with Leslie and try and get whatever training issues remain resolved? RegDate:2009-01-16 Haven't read anything on changes in the announcements, except the we're sending this to PPML (think that's right?), but no announcement on a change of opinion/policy. I have enough mailing lists. If ARIN is incorrectly denying requests, I'll definitely work on getting that resolved. We'll see. I've asked for a do-over, or whatever they called it. /24 seemed a bit much, so I slimmed down to /27, thinking it more appropriate for a 5 year plan (which is what they asked). The beauty is that we don't have to come to rural OK to compete. We can just let them use whatever stingy amount of address space you provide to get a tunnel to us. Sure they'll love the latency. I know I currently do with the mess that is core routing. Anyone who would actually care, probably would request a static, which we are much more lenient with IPv6 than IPv4. However, I can't issue /48 to everyone as things stand. We'll see how it goes with ARIN, now that I know I can ask again and not go through the hassle for nothing. Jack
Re: Definitive Guide to IPv6 adoption
Dobbins, Roland rdobb...@arbor.net writes: Eric Vyncke's IPv6 security book is definitely worthwhile, http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 A good companion to Eric's book is Deploying IPv6 Networks http://www.ciscopress.com/bookstore/product.asp?isbn=1587052105 Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
RE: Definitive Guide to IPv6 adoption
This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers. Develop a plan for /48 per customer, then go to ARIN and get that size block. Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block. Tony -Original Message- From: Brandon Kim [mailto:brandon@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction Thanks again especially on a Saturday weekend! From: rdobb...@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 + Subject: Re: Definitive Guide to IPv6 adoption On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 - -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar. =
Re: Definitive Guide to IPv6 adoption
Unfortunately, it is not as easy as that in practice. I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers. Develop a plan for /48 per customer, then go to ARIN and get that size block. Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block. Tony -Original Message- From: Brandon Kim [mailto:brandon@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction Thanks again especially on a Saturday weekend! From: rdobb...@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 + Subject: Re: Definitive Guide to IPv6 adoption On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 - -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar. =
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 9:33 AM, Tony Hain wrote: This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers. +1 Develop a plan for /48 per customer, then go to ARIN and get that size block. Figure out exactly what you are going to assign to customers later, More accurately... A /48 per customer end-site... but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block. But otherwise, yes, Tony is right. Owen
Re: Definitive Guide to IPv6 adoption
On 10/18/10 9:33 AM, Tony Hain wrote: This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers. Develop a plan for /48 per customer, then go to ARIN and get that size block. Develop a plan, consider the prior art, consider the possibly that you might deploy 6rd, consider what your peers are doing, consider the projections for your business. Go to arin with a request that meets your current and anticipated needs and that is defensible. don't decide without thinking it through that you're assigning a customer a /64 a /60 a /56 or even /48. this should be defensible as part of a business plan, otherwise what's the point? Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block. Tony -Original Message- From: Brandon Kim [mailto:brandon@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction Thanks again especially on a Saturday weekend! From: rdobb...@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 + Subject: Re: Definitive Guide to IPv6 adoption On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 - -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar. =
Re: Definitive Guide to IPv6 adoption
On 10/18/2010 11:47 AM, Randy Carpenter wrote: Unfortunately, it is not as easy as that in practice. I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty. ARIN does reservations (unsure at what length, but at least down to /31). If you were to fill the /32 quickly, you could easily request the next block. To my knowledge, they've only handed out 1 or 2 networks shorter than /32. Correct me if I'm wrong, but isn't 60,000 customers at /56 2^24 assignments from a /32? Seems plenty. Even at /48 assignments, you'd get 65,536 assignments. So how can you justify more than a /32? Jack
Re: Definitive Guide to IPv6 adoption
On 10/18/2010 11:45 AM, Owen DeLong wrote: More accurately... A /48 per customer end-site... Define end0-site. Residential customers, for example, don't need more than a /56. More would just be obscene. Most small businesses don't need more than a /56 either, especially if you are breaking them up into different sites (versus assigning a /48 to customer and dividing that block up to different sites). Jack
Re: Definitive Guide to IPv6 adoption
On 10/18/10 10:10 AM, Jack Bates wrote: On 10/18/2010 11:45 AM, Owen DeLong wrote: More accurately... A /48 per customer end-site... Define end0-site. Residential customers, for example, don't need more than a /56. This is a matter of opinion not gospel. larger, this size, or smaller needs to be justified by your deployment plan. More would just be obscene. Most small businesses don't need more than a /56 either, especially if you are breaking them up into different sites (versus assigning a /48 to customer and dividing that block up to different sites). business customers can and will do whatever is necessary to support their model. I have sought and received a /43 direct assignment for a business will multiple sites. I have no trouble imagining that my upstreams would accommodate requests for PA /48s for each location as well. joel Jack
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 9:47 AM, Randy Carpenter wrote: Unfortunately, it is not as easy as that in practice. I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty. ARIN policy allows for a /48 per end user. There are guidelines included in the policy that allow for a /56 per end-user, but, they are explicitly called out as just guidelines, not policy. I am working on changing the ARIN policy (I've currently circulated a draft to some co-authors and expect to be posting it to pol...@arin.net and p...@arin.net within the next couple of weeks) along the lines you mention. I think that IPv4think is a largely temporary problem, but, it is a problem even at the RIRs. Owen -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers. Develop a plan for /48 per customer, then go to ARIN and get that size block. Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block. Tony -Original Message- From: Brandon Kim [mailto:brandon@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction Thanks again especially on a Saturday weekend! From: rdobb...@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 + Subject: Re: Definitive Guide to IPv6 adoption On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 - -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar. =
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 9:59 AM, Jack Bates wrote: On 10/18/2010 11:47 AM, Randy Carpenter wrote: Unfortunately, it is not as easy as that in practice. I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty. ARIN does reservations (unsure at what length, but at least down to /31). If you were to fill the /32 quickly, you could easily request the next block. To my knowledge, they've only handed out 1 or 2 networks shorter than /32. Not any more... ARIN now uses allocation by bisection. Correct me if I'm wrong, but isn't 60,000 customers at /56 2^24 assignments from a /32? Seems plenty. Even at /48 assignments, you'd get 65,536 assignments. So how can you justify more than a /32? The customers should get /48s. The /56 guideline is merely that and only for the smallest of sites. It's also subsequently turned out to be bad advice. 60,000 customers may well be more than 65,536 end sites. Also, you need to leave room for numbering infrastructure, sizing POPs to prefixes, etc. It's much more complex than just number of customers = number of /48s. Unfortunately, current policy doesn't recognize that other than HD ratio. However, 60,000 customers each with a /48 would far exceed the .94 HD ratio requirement for larger than a /32. IIRC, under current policy it would justify a /30 or possibly a /29. Owen
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 9:53 AM, Joel Jaeggli wrote: On 10/18/10 9:33 AM, Tony Hain wrote: This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers. Develop a plan for /48 per customer, then go to ARIN and get that size block. Develop a plan, consider the prior art, consider the possibly that you might deploy 6rd, consider what your peers are doing, consider the projections for your business. Go to arin with a request that meets your current and anticipated needs and that is defensible. don't decide without thinking it through that you're assigning a customer a /64 a /60 a /56 or even /48. this should be defensible as part of a business plan, otherwise what's the point? A /48 is defensible. It's the architecturally intended end-site configuration, it is allowed by policy, and, it is a reasonable starting point. There is no real reason to assign less than a /48 to any end-site other than hyper- conservatism due to IPv4-think. Owen Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block. Tony -Original Message- From: Brandon Kim [mailto:brandon@brandontek.com] Sent: Saturday, October 16, 2010 1:59 PM To: nanog@nanog.org Subject: RE: Definitive Guide to IPv6 adoption Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction Thanks again especially on a Saturday weekend! From: rdobb...@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 + Subject: Re: Definitive Guide to IPv6 adoption On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 - -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar. =
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 10:10 AM, Jack Bates wrote: On 10/18/2010 11:45 AM, Owen DeLong wrote: More accurately... A /48 per customer end-site... Define end0-site. Residential customers, for example, don't need more than a /56. More would just be obscene. Most small businesses don't need more than a /56 either, especially if you are breaking them up into different sites (versus assigning a /48 to customer and dividing that block up to different sites). You are wrong. Residential customers should get /48s. /56s seemed like a good idea at the time, but, they aren't. It's not just about counting subnets. There's also the issue of needing bits for self-defining hierarchical topologies. 8 bits isn't enough for that. 16 is. Seriously... This isn't IPv4. The scarcity mentality is causing harm and driving decisions that will have a limiting effect on innovation that is already in progress. Owen
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: ARIN does reservations (unsure at what length, but at least down to /31). Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... Regards, -drc
Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation
On Oct 18, 2010, at 2:18 PM, David Conrad wrote: On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: ARIN does reservations (unsure at what length, but at least down to /31). Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the sparse allocation approach and it was requested by the community during the ARIN/NANOG Dearborn meeting. FYI, /John John Curran President and CEO ARIN
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 11:18 AM, Jon Lewis wrote: On Mon, 18 Oct 2010, Owen DeLong wrote: The customers should get /48s. The /56 guideline is merely that and only for the smallest of sites. It's also subsequently turned out to be bad advice. Can you elaborate on why /56 is bad advice and if you're saying it only for this case or if you're saying assignment of /56 to any customers is a bad idea? Dealing with a data center where customer machines typically get by today with a /29 of IPv4, is a /56 really not enough for their forseeable future? I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking. In a datacenter environment, you might want to actually assign /64s to needed subnets, but, in a situation where you are serving remote end-sites, a /48 per end-site is, IMHO, the minimum size that should be issued. I realize our /32 could support more customers than we're likely to fit in the data center at /48 per customer, but is that enough of a reason to assign 65k /64 subnets to each customer machine? Datacenter is a whole different ball of wax. Nothing wrong with giving your customers /48s, but, the right size in a datacenter may well depend on a lot of things about your business model, the nature of your customers, etc. Certainly I would not deny a /48 to any customer that requested one. Owen
Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation
John, Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations? -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - On Oct 18, 2010, at 2:18 PM, David Conrad wrote: On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: ARIN does reservations (unsure at what length, but at least down to /31). Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the sparse allocation approach and it was requested by the community during the ARIN/NANOG Dearborn meeting. FYI, /John John Curran President and CEO ARIN
Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation
I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - Randy - We'll likely put that out to the ARIN community for consultation at the point in time when becomes a potential issue. I expect we will have plenty of time before that needs to be considered at the present rate of allocation. /John John Curran President and CEO ARIN On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote: John, Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations? -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - On Oct 18, 2010, at 2:18 PM, David Conrad wrote: On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: ARIN does reservations (unsure at what length, but at least down to /31). Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the sparse allocation approach and it was requested by the community during the ARIN/NANOG Dearborn meeting. FYI, /John John Curran President and CEO ARIN
Re: Definitive Guide to IPv6 adoption
On 10/18/2010 1:20 PM, sth...@nethelp.no wrote: I still haven't seen any good argument for why residential users need /48s. No, I don't think that makes all the address assignments the same size is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. +1 This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy. Jack
Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation
On 10/18/10 12:42 PM, Randy Carpenter wrote: I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. back in the distant past we were issued a /35, policy changed, we returned it and on 2001 7/11 we were issued our current /32 thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - Randy - We'll likely put that out to the ARIN community for consultation at the point in time when becomes a potential issue. I expect we will have plenty of time before that needs to be considered at the present rate of allocation. /John John Curran President and CEO ARIN On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote: John, Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations? -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - On Oct 18, 2010, at 2:18 PM, David Conrad wrote: On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: ARIN does reservations (unsure at what length, but at least down to /31). Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the sparse allocation approach and it was requested by the community during the ARIN/NANOG Dearborn meeting. FYI, /John John Curran President and CEO ARIN
Re: Definitive Guide to IPv6 adoption
So they can't run their own services from home and have to request premium connectivity from you? Beside the IPv4 scarcity mentality we have the Telco mentality to fight... Happy days still ahead... - Original Message - From: Jack Bates jba...@brightok.net To: sth...@nethelp.no Cc: nanog@nanog.org Sent: Tuesday, 19 October, 2010 8:10:35 AM Subject: Re: Definitive Guide to IPv6 adoption On 10/18/2010 1:20 PM, sth...@nethelp.no wrote: I still haven't seen any good argument for why residential users need /48s. No, I don't think that makes all the address assignments the same size is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. +1 This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy. Jack
Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation
Generally the older allocations would be left in place until deprecated by attrition. At least that's what I plan to advocate in my policy proposal. Owen Sent from my iPad On Oct 18, 2010, at 12:42 PM, Randy Carpenter rcar...@network1.net wrote: I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - Randy - We'll likely put that out to the ARIN community for consultation at the point in time when becomes a potential issue. I expect we will have plenty of time before that needs to be considered at the present rate of allocation. /John John Curran President and CEO ARIN On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote: John, Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations? -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - On Oct 18, 2010, at 2:18 PM, David Conrad wrote: On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: ARIN does reservations (unsure at what length, but at least down to /31). Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the sparse allocation approach and it was requested by the community during the ARIN/NANOG Dearborn meeting. FYI, /John John Curran President and CEO ARIN
Re: Definitive Guide to IPv6 adoption
On 10/18/2010 3:51 PM, Franck Martin wrote: So they can't run their own services from home and have to request premium connectivity from you? Beside the IPv4 scarcity mentality we have the Telco mentality to fight... Happy days still ahead... Of course they can run their own services at home. How does renumber effect that (outside of poor v6 implementations at this late stage)? v6 is designed to support multiple prefixes and the ability to change from one prefix to another with limited disruption, especially if I give 24 hours to complete the transition. If servers and services can't handle this, I'd say they need to improve, or the customer will need a static allocation, which we may or may not charge for (depending on how automated we make it). A sane default of rotation is appropriate for us, though, and no amount of fighting by anyone will make the Telco think that google or others have the right to track their users. It's unfair for our users who block cookies, do due diligence to not be tracked, and then we throw them to the wolves with a constant trackable prefix. Jack (knew this would start an argument. *sigh*)
Re: Definitive Guide to IPv6 adoption
On Mon, 18 Oct 2010, Owen DeLong wrote: I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking. Q: Why are /48s everywhere a good idea? A: Because it's the design! Q: Why are /48s everywhere in the design? A? Because it's a good idea! This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place. The model I've been advocating is for ISPs (who have enough space) to start off reserving a /48 per customer and then assigning the first /56 from it. If after real operational experience it turns out /48 is the right answer, you're all set. If /56 turns out to be sufficient, when you use up all of the first /56s you can start on the first /56 in the second /49, etc. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
Re: Definitive Guide to IPv6 adoption
On 10/18/2010 14:39, Doug Barton wrote: On Mon, 18 Oct 2010, Owen DeLong wrote: I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking. Q:Why are /48s everywhere a good idea? A:Because it's the design! Q:Why are /48s everywhere in the design? A?Because it's a good idea! This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place. Dynamic under IPv4, that is. It could be argued that IPv6 brings back the ability to go static everywhere again. ~Seth
Re: Definitive Guide to IPv6 adoption
On Mon, 18 Oct 2010 14:39:19 -0700 (PDT) Doug Barton do...@dougbarton.us wrote: On Mon, 18 Oct 2010, Owen DeLong wrote: I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking. Q:Why are /48s everywhere a good idea? A:Because it's the design! Q:Why are /48s everywhere in the design? A?Because it's a good idea! This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place. The model I've been advocating is for ISPs (who have enough space) to start off reserving a /48 per customer and then assigning the first /56 from it. If after real operational experience it turns out /48 is the right answer, you're all set. If /56 turns out to be sufficient, when you use up all of the first /56s you can start on the first /56 in the second /49, etc. While I like the idea of /48s per customer (per-nearly everybody), I do think this approach is a good, slightly more conservative approach. Regards, Mark.
Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation
On Oct 18, 2010, at 3:42 PM, Randy Carpenter wrote: I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. Just for reference regarding existing IPv6 sparse practice: Our current plan is to use the sparse allocation block (currently a /14) until we fill it up. Bisection done at the /28 boundary which leaves a fairly large reserve. If an organization needs an allocation larger than a /28, we have set aside a /15 block for those larger ISPs. The orgs that already have allocations (/32s from /29s) also have a reserve. If they need additional space, they can either request from their /29 reserve, or if they need more than a /29, can request a new block. Obviously, this can be changed if the community wishes it so. Bring any obvious suggestions to the ARIN suggestion process, and anything which might be contentious or affect allocations to the policy process. Thanks! /John John Curran President and CEO ARIN
Re: Definitive Guide to IPv6 adoption
sth...@nethelp.no writes: I still haven't seen any good argument for why residential users need /48s. No, I don't think that makes all the address assignments the same size is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. If we were to give a /48 to every human on the face of the planet, we would use about .25 of the total available IPv6 address space. You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.9% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo! -r
Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation
John, Thank you very much. That clarification helps out quite a bit. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 - Original Message - On Oct 18, 2010, at 3:42 PM, Randy Carpenter wrote: I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. Just for reference regarding existing IPv6 sparse practice: Our current plan is to use the sparse allocation block (currently a /14) until we fill it up. Bisection done at the /28 boundary which leaves a fairly large reserve. If an organization needs an allocation larger than a /28, we have set aside a /15 block for those larger ISPs. The orgs that already have allocations (/32s from /29s) also have a reserve. If they need additional space, they can either request from their /29 reserve, or if they need more than a /29, can request a new block. Obviously, this can be changed if the community wishes it so. Bring any obvious suggestions to the ARIN suggestion process, and anything which might be contentious or affect allocations to the policy process. Thanks! /John John Curran President and CEO ARIN
Re: Definitive Guide to IPv6 adoption
On Oct 18, 2010, at 8:16 PM, Robert E. Seastrom wrote: sth...@nethelp.no writes: I still haven't seen any good argument for why residential users need /48s. No, I don't think that makes all the address assignments the same size is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. If we were to give a /48 to every human on the face of the planet, we would use about .25 of the total available IPv6 address space. You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.9% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo! It makes a bigger difference if everyone starts using 6RD - to give out a /48 effectively requires a /16, and the number of /16s is by no means approximately infinite. Regards Marshall -r
Re: Definitive Guide to IPv6 adoption
Marshall Eubanks t...@americafree.tv writes: It makes a bigger difference if everyone starts using 6RD - to give out a /48 effectively requires a /16, and the number of /16s is by no means approximately infinite. Don't I know it! Poorly designed protocol, but what're we gonna do? I was of the a /56 was bad enough, don't let the standard what-people-expect slip to a /60 school. I'm pleased that the ARIN AC passed 2010-12 with provision for getting a /24. Keeps the damage from getting worse. But for native deployment, absolutely just provision the /48. -r
Re: Definitive Guide to IPv6 adoption
RS, On Oct 18, 2010, at 2:16 PM, Robert E. Seastrom wrote: If we were to give a /48 to every human on the face of the planet, we would use about .25 of the total available IPv6 address space. Sure. I once did the math that suggested that even if you multiplied the current IPv4 consumption rate by 1000 and applied that consumption rate to IPv6 /48s, the 1/8th of the IPv6 address space used for global unicast would last over 100 years. The problem is that allocation policy depends on who shows up at RIR meetings. Marshall has pointed out the (potential) implications of that policy with respect to 6rd. My math didn't take 6rd into account. Simply, there is no finite resource that people can't figure out a way to waste in an insane fashion. Since IPv6 is a finite resource, I personally think it makes sense for folks to be reasonably conservative in assignment to customers. Regards, -drc
Re: Definitive Guide to IPv6 adoption
In message 35804bc3-9efe-4ce4-b13a-f2e15c420...@americafree.tv, Marshall Euba nks writes: It makes a bigger difference if everyone starts using 6RD - to give out = a /48 effectively=20 requires a /16, and the number of /16s is by no means approximately = infinite.=20 Regards Marshall Only if you deploy 6rd in a naive manner. Encoding all of IPv4 into the IPv6 prefix you hand your customers in naive. The best way is to just have a table that matches 6rd prefixes to IPv4 blocks you have assigned. This table only changes when you add or remove a IPv4 assignments from RIRs. You don't change existing entries in the table. The entries are static for the life of the IPv4 allocation. 6rdPrefix16rdPefixLen1IPv4Prefix1IPv4PrefixLen1 6rdPrefix26rdPefixLen2IPv4Prefix2IPv4PrefixLen2 6rdPrefix36rdPefixLen3IPv4Prefix3IPv4PrefixLen3 When you configure a IPv4 DHCP pool and associated router interface you find the covering IPv4 prefix and plug in the values from the table. The next best way is to have a similar table but per covering IPv4/8 you have allocated. This is very wasteful but not as having a IPv4PrefixLen of 0. 6rdPrefix16rdPefixLen192.0.0.08 6rdPrefix26rdPefixLen202.0.0.08 For the global naive case the table degenerates to a single row. 6rdPrefix6rdPefixLen0.0.0.00 As a exercise the first table was ~20 entries for Comcast Cable and the second table about ~10 entries if I did the lookup correctly so we are not talking about a lot of prefixes and they don't change very often. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
RE: Definitive Guide to IPv6 adoption
-Original Message- From: Robert E. Seastrom Sent: Monday, October 18, 2010 5:17 PM To: sth...@nethelp.no Cc: nanog@nanog.org Subject: Re: Definitive Guide to IPv6 adoption You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.9% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo! -r I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it.
Re: Definitive Guide to IPv6 adoption
On 10/18/2010 7:16 PM, Robert E. Seastrom wrote: You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.9% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo! Thanks. Actually, I think people are following the RIR example. ARIN handed out a /32 as standard for an ISP, so a /32 is the framework even a medium sized ISP will use. Our routing/IP Numbering Plan: regional assignmentpop assignmentcustomer assignment /40 regional assignment supporting 256 regional assignments /44 for only 16 pop assignments? /48 to customer for only 16 customers per pop assignment? Perhaps another view /40 regional assignment supporting 256 regional assignments /44 still for 16 pop assignments /56 to customer for 4096 customer assignments I'm sorry, but I just couldn't find a way to make /48 to customers work appropriately, and ARIN seems to think a /32 is fair, yet I have to design an IP assignment plan up front to make for more efficient routing. I actually expect a /42-/43 per pop, and /38 per region even in the /56 to customer model. Jack
Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 5:22 PM, Franck Martin wrote: You give a /64 to the end users (home/soho), and /48 to multi homed organization (or bigger orgs that use more than one network internally) and get a /32 if you are an ISP. Please DON'T do that. End users (home/soho) should get at least a /56 and ideally a /48. The standards and the RIR policies both allow for end-users/sites to get /48s. If you are an ISP, you get AT LEAST a /32. See also the discussion about what to use in p2p links. Yep. Personally, I like the /64 per subnet including p2p link approach. Others have different opinions. Owen - Original Message - From: Brandon Kim brandon@brandontek.com To: nanog@nanog.org Sent: Sunday, 17 October, 2010 8:58:57 AM Subject: RE: Definitive Guide to IPv6 adoption Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction Thanks again especially on a Saturday weekend! From: rdobb...@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 + Subject: Re: Definitive Guide to IPv6 adoption On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 8:36 AM, Brandon Kim wrote: Since we are on the topic of IPv6. I'd like to know if anyone has books/articles they recommend on fully understanding IPv6 adoption in the work place. I will need to contact ARIN shortly to request a v6 block. I'm assuming I would be asking for a /64 being an ISP. But I'd like to read up as much as possible before requesting the block No, as an ISP, you should get at least a /32. A /64 is a single subnet in IPv6. I think our approach will be to use dual-stack on the routers and let the clients themselves handle how they want to use IPv6... Seems reasonable. FWIW, you should plan for assigning clients a /48 per end-site. Ultimately, it is up to them, their network, and their applications on how to use v6... Yep. Owen
Re: Definitive Guide to IPv6 adoption
Joel's widget number 2 On Oct 16, 2010, at 8:36, Brandon Kim brandon@brandontek.com wrote: Since we are on the topic of IPv6. I'd like to know if anyone has books/articles they recommend on fully understanding IPv6 adoption in the work place. I will need to contact ARIN shortly to request a v6 block. I'm assuming I would be asking for a /64 being an ISP. But I'd like to read up as much as possible before requesting the block An ISP requesting an assignment would typically request a /32 For policy, I'd read the ARIN nrpm's section on v6 assignment. https://www.arin.net/policy/nrpm.html#six I'd also get a book, for background, something like: http://www.amazon.com/Running-IPv6-Iljitsch-van-Beijnum/dp/1590595270/ref=sr_1_3?ie=UTF8qid=1287244118sr=8-3#reader_1590595270 Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. I think our approach will be to use dual-stack on the routers and let the clients themselves handle how they want to use IPv6... Ultimately, it is up to them, their network, and their applications on how to use v6... Thanks guys!
Re: Definitive Guide to IPv6 adoption
On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
RE: Definitive Guide to IPv6 adoption
Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction Thanks again especially on a Saturday weekend! From: rdobb...@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 + Subject: Re: Definitive Guide to IPv6 adoption On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
Re: Definitive Guide to IPv6 adoption
You give a /64 to the end users (home/soho), and /48 to multi homed organization (or bigger orgs that use more than one network internally) and get a /32 if you are an ISP. See also the discussion about what to use in p2p links. - Original Message - From: Brandon Kim brandon@brandontek.com To: nanog@nanog.org Sent: Sunday, 17 October, 2010 8:58:57 AM Subject: RE: Definitive Guide to IPv6 adoption Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction Thanks again especially on a Saturday weekend! From: rdobb...@arbor.net To: nanog@nanog.org Date: Sat, 16 Oct 2010 16:09:43 + Subject: Re: Definitive Guide to IPv6 adoption On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sell your computer and buy a guitar.
