Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 4-Feb-2009, at 22:59, Mikael Abrahamsson wrote: On Wed, 4 Feb 2009, Joe Abley wrote: I see people predicting that giving everybody a /56 is insane and will blow out routing tables. I don't quite understand that; at the regional ISP with which I am most familiar 40,000 or so internal/ customer routes in BGP, and I have not noticed anything fall over. This is 2008: we are not dealing with routers maxed out with 256MB of RAM. And this is without any attempt to aggregate per LNS, or per POP. What you do is that you do /40-44 per router or so and announce this to the rest of the network, then internally from that you assign /48 to /56 per customer out of that block. IPv6 enables us to lower address use and get less routes in the core network (both within the ISP and globally). That has the down-side today that you require customers to support DHCPv6 PD in order to get their /56, though. For some providers that might be simple to organise (e.g. business- focussed ISPs whose customers use a reliably-small set of CPE). For residential customers, however, I think it's far more likely to be problematic, and hence the idea of retaining the option for static configuration seems prudent, at least at this early stage in the game. Static configuration means you need the assignment to be consistent regardless of which LNS the customer lands on. I appreciate that this approach may well be a luxury only available to relatively small ISPs, and that the approach will quite possibly need to change in the future. But it seems like a reasonable way to go for now. Joe
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Wed, 4 Feb 2009, Joe Abley wrote: I see people predicting that giving everybody a /56 is insane and will blow out routing tables. I don't quite understand that; at the regional ISP with which I am most familiar 40,000 or so internal/customer routes in BGP, and I have not noticed anything fall over. This is 2008: we are not dealing with routers maxed out with 256MB of RAM. And this is without any attempt to aggregate per LNS, or per POP. What you do is that you do /40-44 per router or so and announce this to the rest of the network, then internally from that you assign /48 to /56 per customer out of that block. IPv6 enables us to lower address use and get less routes in the core network (both within the ISP and globally). -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
On 4-Feb-2009, at 19:05, Roger Marquis wrote: Mark Andrews wrote: All IPv6 address assignments are leases. Whether you get the address from a RIR, LIR or ISP. The lease may not be renewed when it next falls due. You may get assigned a different set of addresses at that point. You should plan accordingly. Exactly the problem, In the regional ISP I alluded to in my previous message, /56es are assigned to residential DSL customers and are static (they are handed out to the LNS from RADIUS). The link address (IPV6CP + ND/RA) depends on the particular LNS your PPP session lands on, however. and the reason A) IPv6 is not and will not be a viable option any time soon (soon being before the publication of an IPv6 NAT RFC), and B) why network providers (and other parties who stand to gain financially) are firmly against IPv6 NAT. In this case there is no religion for or against NAT inherent in the v6 access service being provided. Customers can do what they want with the addresses provided to them. Joe
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Wed, Feb 4, 2009 at 10:45 PM, Mark Andrews wrote: > >We already know some will need more than a /48. /48 was >only ever described as meeting the requirements of *most* >business and consumers. > so.. what businesses need is not actually 'more than one /48' but real, useful, doable multihoming. A /48 is fine if you have only one site, it's been used to solve 2 of 3 problems: 1) my addresses don't have to change (if I only have one site) 2) I can multihome with a single address on my devices/hosts (cause the original v6 plan for that was just dumb) It doesn't solve the problem of an enterprise with more than one location/network-interconnect... we can go around this rose bush again and again and again, but honestly, deployment of v6 happens for real when there is a significant business reason to deploy it, and when the real concerns of enterprises today are actually addressed. -Chris
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 4-Feb-2009, at 16:16, Patrick W. Gilmore wrote: I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem. All the advice I have heard about address assignment to broadband subscribers is to give each subscriber a /56, in addition to the link address (which is effectively a /128). The last time I looked, the v6 allocation of every RIR apart from ARIN recommended a /48 instead of a /56. I have been specifically advised against assigning a /64 per subscriber on the grounds that it is short-sighted, since v6 residential gateways, when they come in large numbers, will expect to be able to assign addresses to more than one subnet in the customer network. And before anyone says "there are 281474976710656 /48s!", just remember your history. The pertinent numbers given the thinking above are 2^24 == 16,777,216 customer /56 assignments , or 2^16 == 65536 customer /48 assignments per /32 allocation from an RIR. (If a /32 is all you have, then you will want to reserve some of that space for your own infrastructure, and the numbers above will be slightly higher than reality.) I see people predicting that giving everybody a /56 is insane and will blow out routing tables. I don't quite understand that; at the regional ISP with which I am most familiar 40,000 or so internal/ customer routes in BGP, and I have not noticed anything fall over. This is 2008: we are not dealing with routers maxed out with 256MB of RAM. And this is without any attempt to aggregate per LNS, or per POP. (This regional ISP is close to being able to provide responses to IPV6CP requests for all customers to establish an interface id, ND/RA to assign a link address, and DHCPv6 PD on request, for all customers; it's working in the lab, but hasn't yet been rolled out on the production access routers, which are all Juniper E-series devices. No, there's no direct revenue in it today; yes, the vast majority of customers are probably using XP or a residential gateway that will never talk v6.) If you need to worry about the impact on your internal routing tables of internal customer growth, then it seems you should be more worried about the impact on your routing tables of growth in the global v4 table (which is surely more rapid, and arguably can be expected to accelerate as v4 exhaustion leads to imaginative inter-organisation address assignment for fee). I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $...@#%'ing way we will EVER use THAT many" I suspect that for many regional ISPs a single allocation sufficient to number 16 million customers is probably good enough. In Canada, for example, that's half the total population, and probably larger than the total number of residences. No doubt there are a countable and significant number of super-ISPs in larger markets (or spanning multiple markets) that have requirements that out-strip that of a single /32, but I feel comfortable predicting that they are the minority in the grand scheme of things (and in any case, they can always request a larger allocation). Joe
Re: Private use of non-RFC1918 IP space (IPv6-MW)
--On onsdag, onsdag 4 feb 2009 19.02.56 -0500 "Patrick W. Gilmore" wrote: > Second, where did you get 4 users per /64? Are you planning to hand each > cable modem a /64? Telia got their /20 based on calculations where they give every customer a /48. Every apartment in every highrise gets 2^16 networks. I think that /56 or /52 is a more appropriate allocation per broadband subscriber. -- Måns NilssonM A C H I N A ... he dominates the DECADENT SUBWAY SCENE. pgp9epLSXt9oD.pgp Description: PGP signature
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
On Wed, Feb 4, 2009 at 10:45 PM, Mark Andrews wrote: > > In message <20090205030522.13d152b2...@mx5.roble.com>, Roger Marquis > writes: > > Mark Andrews wrote: > > > All IPv6 address assignments are leases. Whether you get > > > the address from a RIR, LIR or ISP. The lease may not be > > > renewed when it next falls due. You may get assigned a > > > different set of addresses at that point. You should plan > > > accordingly. > > > > Exactly the problem, and the reason A) IPv6 is not and will not be a > viable > > option any time soon (soon being before the publication of an IPv6 NAT > > RFC), and B) why network providers (and other parties who stand to gain > > financially) are firmly against IPv6 NAT. > What about costs? If you're a realist, you know that v6 migration is a cost problem. Ask cable or DSL providers across the world what percentage of their user base CPE is v6 compatable and the answer will likely be shocking. In this economy, unless the seondary market is egregiously expensive, don't expect to see a mass migration. There's also the problem of no known commericial grade NAT device (SLA worthy) that makes this easier. Thoughts appreciated. Best, Martin -- Martin Hannigan mar...@theicelandguy.com p: +16178216079
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
Apologies if this message is brief, it is sent from my cellphone. Begin forwarded message: From: Nathan Ward On 5/02/2009, at 16:58, Chris Adams wrote: Since NAT == stateful firewall with packet mangling, it would be much easier to drop the packet mangling and just use a stateful firewall. You are just reinforcing the incorrect belief that "NAT == security, no-NAT == no-security". Not entirely. There was a lengthy and heated debate on this list about 6 months ago, where the point was raised that many people like to use NAT because it provides some level of anonymity in thier network. Obviously this only applies for networks with enough people that that has an effect. IPv6 has privacy addresses to address this concern.
Seeking FIOS tech support with two (or more) brain cells
Hi folks, Does anyone know any kind of super-secret back door number for Verizon FIOS tech support for people-with-a-clue? I can hear the drool hitting the keyboard on the other end of the line and the confusion in the voice of the support rep when I try to get help with turning up a "business" (ha!) FIOS circuit with five static addresses on it. Things have sure gone downhill since they decided that a MOCA handoff was a good idea; I turned one of these up for another friend a year ago and it was 100% plug and chug... Before you flame me, yes, I tried the database on puck.nether.net to see if I could pull something off via that route, but no joy. -r
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
I am told that juniper have just released their E series code to do hitless failover and ipv6cp at the same time. If you are not running hitless it has been working for some time. Apologies if this message is brief, it is sent from my cellphone. On 5/02/2009, at 17:29, Matthew Moyle-Croft wrote: Hi James, I don't think anyone really has done it large scale properly. I've had basically nothing from anyone. Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!). There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience. Scary huh? I'm meant to have 250,000 customers running it by Christmas! MMC On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote: Hello Matthew , See way below ... On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: Scott Howard wrote: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore >wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >wrote: but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . Twyl , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | Network&System Engineer | 2133McCullam Ave | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +--+ -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909 !DSPAM:22,498a6b69305768916813158!
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
Seth Mattinen wrote: Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall. NAT provides some security, often enough to make a firewall unnecessary. It all depends on what's inside the edge device. But really, I've never heard anyone seriously equate a simple NAT device with a firewall. People do, and justifiably, equate NAT with the freedom to number, subnet, and route their internal networks however they choose. To argue against that freedom is anti-consumer. Continue to ignore consumer demand and the marketplace will continue to respond accordingly. Give consumers a choice (of NAT or not) and they will come (to IPv6). It's just about as simple as that. Well, that and a few unresolved issues with CAMs, routing tables, and such. Roger Marquis
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Hmm, Apologies for that - wasn't meant to goto the list. Was a bit "frank". MMC On 05/02/2009, at 2:59 PM, Matthew Moyle-Croft wrote: Hi James, I don't think anyone really has done it large scale properly. I've had basically nothing from anyone. Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!). There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience. Scary huh? I'm meant to have 250,000 customers running it by Christmas! MMC On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote: Hello Matthew , See way below ... On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: Scott Howard wrote: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore >wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >wrote: but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . Twyl , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | Network&System Engineer | 2133McCullam Ave | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +--+ -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909 -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Hi James, I don't think anyone really has done it large scale properly. I've had basically nothing from anyone. Given my knowledge of where most large BRAS/Cable vendors are upto - I don't think anyone could have. (Cisco won't have high end v6 pppoe support until late this year!). There's a lot of people who clearly don't work for ISPs yammering on about the Zen of v6, but no one with real experience. Scary huh? I'm meant to have 250,000 customers running it by Christmas! MMC On 05/02/2009, at 2:44 PM, Mr. James W. Laferriere wrote: Hello Matthew , See way below ... On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: Scott Howard wrote: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore >wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft >wrote: but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . Twyl , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | Network&System Engineer | 2133McCullam Ave | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +--+ -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Hello Matthew , See way below ... On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: Scott Howard wrote: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft wrote: but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? Has Anyone responded to you on/off list with even a close approximation of showing they have accomplished what you've requested ? I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . Twyl , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | Network&System Engineer | 2133McCullam Ave | Give me Linux | | bab...@baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +--+
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
Once upon a time, Roger Marquis said: > * NAT advantage #5: it does not require replacement security measures to > protect against netscans, portscans, broadcasts (particularly microsoft > netbios), and other malicious inbound traffic. Since NAT == stateful firewall with packet mangling, it would be much easier to drop the packet mangling and just use a stateful firewall. You are just reinforcing the incorrect belief that "NAT == security, no-NAT == no-security". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
In message <20090205030522.13d152b2...@mx5.roble.com>, Roger Marquis writes: > Mark Andrews wrote: > > All IPv6 address assignments are leases. Whether you get > > the address from a RIR, LIR or ISP. The lease may not be > > renewed when it next falls due. You may get assigned a > > different set of addresses at that point. You should plan > > accordingly. > > Exactly the problem, and the reason A) IPv6 is not and will not be a viable > option any time soon (soon being before the publication of an IPv6 NAT > RFC), and B) why network providers (and other parties who stand to gain > financially) are firmly against IPv6 NAT. > > > If we could get a true accounting of the extra cost imposed > > by NAT's I would say it would be in the trillions of dollars. > > This is exactly the sort of hyperbole, like RFC4864's proposing that > application-layer proxies are a viable substitute for NAT, that discredits > IPv6 proponents. Those who remember the financial industry's push for SET, > a failed encryption technology, will be struck by the similarities in > technical vs rhetorical arguments. > > Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network > engineers will be interested in the rational behind statements like: > > * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what > it saves consumers, ILECs, or ISPs?) > * NAT disadvantage #2 (re: your IPv6 address space) Owned by an ISP? It > isn't much different than it is now. (say again?) > > * NAT disadvantage #3: RFC1918 was created because people were afraid of > running out of addresses. (in 1992?) > > * NAT disadvantage #4: It requires more renumbering to join conflicting > RFC1918 subnets than would IPv6 to change ISPs. (got stats?) > > * NAT disadvantage #5: it provides no real security. (even if it were true > this could not, logically, be a disadvantage) > > OTOH, the claimed advantages of NAT do seem to hold water somewhat better: > > * NAT advantage #1: it protects consumers from vendor (network provider) > lock-in. Nope. > * NAT advantage #2: it protects consumers from add-on fees for addresses > space. (ISPs and ARIN, APNIC, ...) Only until the consumers get wind of any rip-off pricing. RIR's are charging ISP's about the same for a IPv6 /48 as they do the a IPv4 address. > * NAT advantage #3: it prevents upstreams from limiting consumers' > internal address space. (will anyone need more than a /48, to be asked in > 2018) We already know some will need more than a /48. /48 was only ever described as meeting the requirements of *most* business and consumers. > * NAT advantage #4: it requires new (and old) protocols to adhere to the > ISO seven layer model. Given were are running IP that is fiticious. > * NAT advantage #5: it does not require replacement security measures to > protect against netscans, portscans, broadcasts (particularly microsoft > netbios), and other malicious inbound traffic. What replacement? You just buy a IPv6 router with a firewall. It will be about the same cost as a IPv4 router with a NAT. > IMHO, > Roger Marquis > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
>> All IPv6 address assignments are leases. Whether you get >> the address from a RIR, LIR or ISP. The lease may not be >> renewed when it next falls due. You may get assigned a >> different set of addresses at that point. You should plan >> accordingly. > >Exactly the problem, and the reason A) IPv6 is not and will not be a viable >option any time soon (soon being before the publication of an IPv6 NAT RFC), >and B) why network providers (and other parties who stand to gain >financially) are firmly against IPv6 NAT. A) I think you have a different definition of viable than I do. I have v6 today, running just fine. Not as a home user, yet - but that is coming in the foreseeable future and has nothing to do with the presence of NAT66, or lack thereof. B) I am not a service provider, and I still tend to dis-favor NAT. Not as vehemently as some, but I for the most part, fail to see the need. > >> If we could get a true accounting of the extra cost imposed by NAT's >> I would say it would be in the trillions of dollars. > >This is exactly the sort of hyperbole, like RFC4864's proposing that >application-layer proxies are a viable substitute for NAT, that discredits >IPv6 proponents. Those who remember the financial industry's push for SET, >a failed encryption technology, will be struck by the similarities in >technical vs rhetorical arguments. While I generally try to avoid the NAT vs NONAT religious debate ... I'll throw in a few comments. > >Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network >engineers will be interested in the rational behind statements like: And I suspect lots of new-to-IPv6 network engineers could benefit from more IPv6 exposure :). > > * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what > it saves consumers, ILECs, or ISPs?) Developed a peer-to-peer application lately? I haven't, but I know some of the issues others have had to go through to work in spite of NAT. > > * NAT disadvantage #2 (re: your IPv6 address space) Owned by an ISP? It > isn't much different than it is now. (say again?) Sorry, your befuddlement has passed on to me - I am not sure what you are saying here. The best I can pull from that would be something about PI vs PA space, and I'd comment that both are now available. > * NAT disadvantage #3: RFC1918 was created because people were afraid of > running out of addresses. (in 1992?) Is that a question? > * NAT disadvantage #4: It requires more renumbering to join conflicting > RFC1918 subnets than would IPv6 to change ISPs. (got stats?) Actually, I think those are different points. NAT-space collisions are a REAL problem, and renumbering due to changing ISPs is also a REAL problem. > * NAT disadvantage #5: it provides no real security. (even if it were true > this could not, logically, be a disadvantage) It is a disadvantage if people believe it is a security thing when it isn't. >OTOH, the claimed advantages of NAT do seem to hold water somewhat better: > > * NAT advantage #1: it protects consumers from vendor (network provider) > lock-in. OK, use PI space. > * NAT advantage #2: it protects consumers from add-on fees for addresses > space. (ISPs and ARIN, APNIC, ...) IPv6 addresses (network allocations, actually) are pretty inexpensive ... > * NAT advantage #3: it prevents upstreams from limiting consumers' > internal address space. (will anyone need more than a /48, to be asked in > 2018) Yes, /48s have already been outgrown ... so you call up your ISP and justify more, they give it to you. No fuss, no muss. > * NAT advantage #4: it requires new (and old) protocols to adhere to the > ISO seven layer model. Actually, it does more than that. You are thinking of "traditional" network apps, client-server stuff. Think end to end / peer to peer (and I don't mean illegal file sharing) ... > * NAT advantage #5: it does not require replacement security measures to > protect against netscans, portscans, broadcasts (particularly microsoft > netbios), and other malicious inbound traffic. Depends on the NAT mode (1:1 or PAT; cone or restricted), and a stateful firewall provides more/real protection ... again, I am not a radical anti-NAT person, I just don't like the pro-NAT hyperbole any more than you favor the opposite :). IMHO /TJ
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Leo Bicknell wrote:
In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew
Moyle-Croft wrote:
My FEAR is that people ("customers") are going to start assuming that v6
means their own static allocation (quite a number are assuming this).
This means that I have a problem with routing table size etc if I have
to implement that.
Customers don't want static addresses.
Customers want many different things.
Customers don't think of their networks at home or in their offices as
part of an ISP network. They think of it as an island that they control
and run and which they buy connectivity to the internet to. They want
flexibility and not the "evil ISP" telling THEM what to do or making
them spend money on their IT consultants to change things when an ISP
wants to renumber.
They want DNS that works, with their own domain names, forward and
reverse.
Yep, but many want to run it themselves, independantly of an ISP.
They want renumbering events to be infrequent, and announced in
advance.
Where infrequent = never.
They want the box the cable/dsl/fios provider to actually work,
that is be able to do really simple stuff without having to buy
another stupid box to put behind it.
Well, we let them chose here in AU ...
None of these require static, and in fact I'd think it would be
easier to get it right than it would be to do statics for most
providers. But, I must be wrong, since the only solution virtually
every provider offers is to "move up" to "a static IP".
I think some customers would like us to spend money running DNS for them
for free, but most who care want to do it independently of us.
MMC
--
Matthew Moyle-Croft - Internode/Agile - Networks
Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: m...@internode.com.au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: Private use of non-RFC1918 IP space (IPv6-MW)
On 5/02/2009, at 3:09 PM, Matthew Moyle-Croft wrote: TJ wrote: No, we should hand each home a /56 (or perhaps a /48, for the purists out there) - allowing for multiple segments (aka subnet, aka links, etc.). If there are, say, 250-500 million broadband services in the world (probably more) then, if every ISP followed best practise for IPv6 address allocation, (sparse, bits for infrastructure, whatever etc) then what percentage of the space do we have left if we hand out /56 or /48s?). Taking into account the space already carved off for link local, private addressing, US Military etc. Has anyone done some analysis of what this might look like? Especially with growth etc. My addressing plan works like this: ISP gets /32, 2001:db8::/32 - 2001:db8:0::/48 = ISP use -- 2001:db8:0:0::/64 = infrastructure --- 2001:db8:0:0:0:0:0::/112 = loopbacks ( 65536 ) --- 2001:db8:0:0:1:0:0::/112 through 2001:db8:::::0/112 = / 112 link nets between ISP routers ( 281474976710656 ) -- 2001:db8:0::/64 through 2001:db8:0:::/64 = ISP networks, ie. servers, etc. - 2001:db8:1::/64 through 2001:db8::::/64 = customer networks. Assuming the above, we have 65535 /48s available to customers, or 16,711,680 /56s. The "ISP use" /48 burns 256 /56s, or potential customers. So, like burning a /24 for the entire ISP operation. So, if you have more than 65K business customers, get more than a /32. If you have more than 16M residential or small business customers, get more than /32. The above plan puts the addresses you type lots (loopbacks, link nets) on the shortest addresses you have - you can use the zero compression :: thing. These are also the addresses that cause the most trouble if fat fingered, so shorter addresses leave less room for error. In addition, the entire first /64 (loopbacks, link nets) should never really receive packets from outside the network. Drop in an ACL. Modification to the above plan is to use /64s for link nets between ISP routers, if you are worried about compatibility issues. You now have a trade off between 65k ISP server networks, and 65k link nets. Let's say 32k for each. -- Nathan Ward
RE: Private use of non-RFC1918 IP space (IPv6-MW)
>Has anyone done some analysis of what this might look like? Especially with growth etc. Sure, probably lots of people lots of times. Off the top of my head, using some current/common allocations sizes: Current "Global Unicast" space --> 2000::/3 An "average" RIR --> /12 an "average" ISP --> /32 an average enterprise --> /48 an average home user --> /56 So, "the current IPv6 world" (2000::/3) can support 512 standard RIR sized allocations. Each standard RIR can support 1M standard ISPs. Each standard ISP can support 64K enterprises or 16M standard home-users, or some combination thereof. So -How much do we want held in reserve? How "flexibly" (ref RFC3531) are we allocating our addresses? How many total (enterprise | home) clients do we want to support? Off the cuff, let's say we use left-most (sparse) allocation and only hit 50% efficiency (keeping the right-most bit totally in reserve!) ... If I am an ISP, and I have 300M home users (/56s) I just need a /26, and that actually gives me a lot of room for more clients (like 200M more). So - what was the problem again? Let's make it even more interesting - let's say I am an ISP, I am allocating /48s, and I need to support - say - 6B assignments for every person in the world + 2B for every organization in the world (#s chosen arbitrarily, feel free to add another bit if it makes you feel better). Bearing in mind that this means every single person and organization has 64k subnets, each of which contains "as many hosts as is appropriate", and all of these are globally routable ... I "just" need a /15 to cover this absolute worst case. Heck, let's make it /14 for good measure. So now each standard RIR can "only" support 4 of this size service provider, but we still have 512 RIR sized allocations. If the individuals got /56s instead these numbers getting even bigger ... So - what was the problem again? Oh, and this is just from the 2000::/3 range ... next up, 4000::/3 ... 6000::/3, 8000::/3, a000::/3, c000::/3. And if we feel like we burned through 2000::/3 too fast at some point in the future, maybe we revisit the rules around the time we start thinking about allocating from 4000::/3? (Or "skip one", and star the new rules with 6000::/3 ... I am not picky). Note, I am _NOT_ saying we should be careless or cavalier about address allocation, just saying we don't live in a constrained situation. And if there is a choice to be made between scalability/flexibility/summarization'ability (is that a word?) and strict efficiency ... the efficiency loses. /TJ PS - Yes, 4.3B seemed really big at one point ... but seriously, do the above numbers not _really_ sound big enough?
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
Mark Andrews wrote: All IPv6 address assignments are leases. Whether you get the address from a RIR, LIR or ISP. The lease may not be renewed when it next falls due. You may get assigned a different set of addresses at that point. You should plan accordingly. Exactly the problem, and the reason A) IPv6 is not and will not be a viable option any time soon (soon being before the publication of an IPv6 NAT RFC), and B) why network providers (and other parties who stand to gain financially) are firmly against IPv6 NAT. If we could get a true accounting of the extra cost imposed by NAT's I would say it would be in the trillions of dollars. This is exactly the sort of hyperbole, like RFC4864's proposing that application-layer proxies are a viable substitute for NAT, that discredits IPv6 proponents. Those who remember the financial industry's push for SET, a failed encryption technology, will be struck by the similarities in technical vs rhetorical arguments. Perhaps what we need is an IPv6 NAT FAQ? I'm suspect many junior network engineers will be interested in the rational behind statements like: * NAT disadvantage #1: it costs a lot of money to do NAT (compared to what it saves consumers, ILECs, or ISPs?) * NAT disadvantage #2 (re: your IPv6 address space) Owned by an ISP? It isn't much different than it is now. (say again?) * NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?) * NAT disadvantage #4: It requires more renumbering to join conflicting RFC1918 subnets than would IPv6 to change ISPs. (got stats?) * NAT disadvantage #5: it provides no real security. (even if it were true this could not, logically, be a disadvantage) OTOH, the claimed advantages of NAT do seem to hold water somewhat better: * NAT advantage #1: it protects consumers from vendor (network provider) lock-in. * NAT advantage #2: it protects consumers from add-on fees for addresses space. (ISPs and ARIN, APNIC, ...) * NAT advantage #3: it prevents upstreams from limiting consumers' internal address space. (will anyone need more than a /48, to be asked in 2018) * NAT advantage #4: it requires new (and old) protocols to adhere to the ISO seven layer model. * NAT advantage #5: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft netbios), and other malicious inbound traffic. IMHO, Roger Marquis
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
TJ wrote: However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable. Also - does DHCPv6 currently have an option for prefix length? Just asking. I'm under no allusion that a /64 is going to be optional - it's really too late which is sad. I think people have just latched onto it and now accept it and defend it without thinking about "is this still the answer?". Just because it's in an RFC doesn't mean it's still the right answer in a changing world. WRT /64s (or really, /56s and /48s being assigned to clients) - note that these are NOT static assignments permanently belonging to the client. They are hopefully dynamic, hopefully via DHCPv6-PD (hopefully available/supported by then) ... similar to the single public IPv4 address most of us dynamically get @home today. Yep - that's what I'm hoping (as I've said and clarified). But I think the reality is that in the provider world, no matter what people here say, customer demand for an unchanging IPv6 range will increase not decrease - driving up provider routing size and complexity. -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: Private use of non-RFC1918 IP space
On Wed, 04 Feb 2009 20:35:15 -0500, James R. Cutler wrote: Clarification here: 1/8 was never on the EDS backbone. Was only used locally in one site, as far as I can determine. They might have done that for other customers as well. (to avoid 10/8 collisions.) Personally, I'd think if they were going to NAT at the edge, they'd only set it up for the machines we were supposed to use, instead, we could see, well, a lot more than we should have. --Ricky
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew
Moyle-Croft wrote:
> My FEAR is that people ("customers") are going to start assuming that v6
> means their own static allocation (quite a number are assuming this).
> This means that I have a problem with routing table size etc if I have
> to implement that.
Customers don't want static addresses.
They want DNS that works, with their own domain names, forward and
reverse.
They want renumbering events to be infrequent, and announced in
advance.
They want the box the cable/dsl/fios provider to actually work,
that is be able to do really simple stuff without having to buy
another stupid box to put behind it.
None of these require static, and in fact I'd think it would be
easier to get it right than it would be to do statics for most
providers. But, I must be wrong, since the only solution virtually
every provider offers is to "move up" to "a static IP".
--
Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
pgpLTGKuEROCj.pgp
Description: PGP signature
Re: Private use of non-RFC1918 IP space (IPv6-MW)
TJ wrote: No, we should hand each home a /56 (or perhaps a /48, for the purists out there) - allowing for multiple segments (aka subnet, aka links, etc.). If there are, say, 250-500 million broadband services in the world (probably more) then, if every ISP followed best practise for IPv6 address allocation, (sparse, bits for infrastructure, whatever etc) then what percentage of the space do we have left if we hand out /56 or /48s?). Taking into account the space already carved off for link local, private addressing, US Military etc. Has anyone done some analysis of what this might look like? Especially with growth etc. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
>My FEAR is that people ("customers") are going to start assuming that v6
>means their own static allocation (quite a number are assuming this).
>This means that I have a problem with routing table size etc if I have to
>implement that.
Then work with them to break them of this dis-illusion.
>I'm still not convinced though that, given DHCPv6 is going to be a reality
>for DNS assignment etc, that stateless autoconfig is needed and thus /64
>doesn't have to be the smallest we assign.
Yes and no. You sound like you are of the belief that SLAAC is bad / deficient
- while it may not be perfect, some are big fans of its ease of use ATLEAST in
certain deployment models.
Re: Private use of non-RFC1918 IP space (IPv6-MW)
TJ wrote: >> Some devices will refuse to work if you subnet smaller than a /64. (Yes, >> poorly designed, etc.) > > Actually, no - not poorly designed. The spec says it must be a /64 > (excluding those starting with 000 binary) so that is what devices > (rightfully) expect. Ref: http://tools.ietf.org/html/rfc4291#section-2.5.1 > I was just trying to head off the flood of "poorly designed" comments last time I said such a thing on a different list. ;) I find /64 convenient because it ends on a nice boundary out of my /48 and for my purposes it's more than enough space. The only annoyance I've come across was my Cisco devices will only accept an EUI-64 address as a host address in an ACL. Not a big deal though. ~Seth
RE: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
>Let's face it - the current v6 assignment rules are to solve a 1990s set >of problems. Perhaps, time moves ever forward. >A /64 isn't needed now that we have DHCP(v6). Setting >the idea in people's heads that a /64 IS going to be their own statically is >insane and will blow out provider's own routing tables more than is >rational. (Think of the processing overhead of all the DSL/Cable customers >going up and down). This is going to be far more of an issue and drive >network design than a minor blow out in the v6 routing table. However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable. Also - does DHCPv6 currently have an option for prefix length? Just asking. WRT /64s (or really, /56s and /48s being assigned to clients) - note that these are NOT static assignments permanently belonging to the client. They are hopefully dynamic, hopefully via DHCPv6-PD (hopefully available/supported by then) ... similar to the single public IPv4 address most of us dynamically get @home today. AND, how does having a route for a /56 impact my routing table more than having a route for a /xx (something longer)?? It does mean the ISP needs a larger initial allocation, but still just one route ... /TJ
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
On 5/02/2009, at 2:35 PM, Scott Howard wrote: What happens when a customer wants to run multiple networks is something I haven't seen answered yet - with NAT it's easy, but as I said, NAT is apparently evil... You give them more than a /64. RFC4291 says that it should be a /48, but people seem to be keen on / 56s now. /60s are even ok. They key here is that is is divisible by 4, which leaves full hex digits for the customer to twiddle. Somewhere (free.fr?) are doing / 61, which is a bit tough for people that aren't so technical. Here in NZ, users typically purchase their own ADSL CPE, and that runs PPPoATM over ADSL, and does IPv4 NAT and so on. What is also common, is people buy a "wireless router" and plug it in to the back of their ADSL router. They now have two layers of NAT between wireless hosts and the Internet. I looked at a packet trace of outgoing packets from an ISP - 17% of outgoing packets were from behind double NAT like this (TTL was 62 or 126, as opposed to 63 or 127). For this topology to work in IPv6, multiple levels of PD are required, or users can no longer do this sort of plug-and-pray networking. Fun fun. Personally, I think we should have PD forwarding - ie. a router can forward PD requests from routers behind it up to the ISP, and the ISP can dish out another /64. It means there are more routes in that particular router at the ISP, but it means you don't have to worry about how much address space to give to each customer - if they need more they ask for it automatically. -- Nathan Ward
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
Scott Howard wrote: On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore wrote: On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft wrote: but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. _should_ As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale. Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave! My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side). The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Tell me about it. As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory? MMC Scott. -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
In message , Scott Howard writes: > On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore wrote: > > > I guess I was thinking about v4 modems which do not get a subnet, just an > > IP address. If we really are handing out a /64 to each DSL & Cable modem, > > then we may very well be recreating the same problem. > > > v4 just gets a single IP address, which is why we need NAT, and apparently > NAT is evil. > > To some extent the /64 can be though of as "just an IP" from the ISP > perspective (in the same sense that an IPv4 IP is just a /32 "network"), > which has the ability for the CPE to then somehow split it out between > multiple hosts - probably using autoconfig (in the same way with IPv4 it's > "split up" by the port with NAT). You hand out multiple /64's. As many as the client requests up to a /56 or /48 depending apon which break point you choose. The address space is assigned to ISP's on the presumption that you will be handing out the equivalent of /56's or /48's worth of address space to each customer. > What happens when a customer wants to run multiple networks is something I > haven't seen answered yet - with NAT it's easy, but as I said, NAT is > apparently evil... > > > On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft wro > te: > > > but my point was that people are starting to assume that v6 WILL mean > > static allocations for all customers. > > > By design IPv6 should mean _less_ static allocations than IPv4 - in the > event that a client disconnects/reconnects and gets a new /64 then their > network *should* automatically handle that fact, with all clients > automagically renumbering themselves to the new /64, updating DNS, etc. > Local communications won't be impacted as they should be using the > link-local address. > > The bit that isn't clear at the moment is if (and how well) that will > actually work in practice. And that brings us back to the good old catch-22 > of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE > not supporting it because ISP don't... > > Scott. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
RE: Private use of non-RFC1918 IP space (IPv6-MW)
>Some devices will refuse to work if you subnet smaller than a /64. (Yes, >poorly designed, etc.) Actually, no - not poorly designed. The spec says it must be a /64 (excluding those starting with 000 binary) so that is what devices (rightfully) expect. Ref: http://tools.ietf.org/html/rfc4291#section-2.5.1 /TJ
RE: Private use of non-RFC1918 IP space (IPv6-MW)
>> On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore >> wrote: >> >>> Except the RIRs won't give you another /48 when you have only used >>> one trillion IP addresses. >> >> Of course they will! A /48 is only the equivalent of 65536 "networks" >> (each network being a /64). Presuming that ISPs allocate /64 networks >> to each connected subscriber, then a /48 is only 65k subscribers, or >> say around a maximum of 200k IP addresses in use at any one time >> (presuming no NAT and an average of 3-4 IP-based devices per >> subscriber) >> >> IPv4-style utilization ratios do make some sense under IPv6, but not >> at the address level - only at the network level. > >First, it was (mostly) a joke. > >Second, where did you get 4 users per /64? Are you planning to hand each >cable modem a /64? No, we should hand each home a /56 (or perhaps a /48, for the purists out there) - allowing for multiple segments (aka subnet, aka links, etc.). Note - the actual number of hosts is irrelevant; the 64 bits on the host side of the address are not meant to encourage 18BB hosts/segment. Oh, and utilization should be based on /56s anyway. /TJ
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
-- m...@internode.com.au wrote: From: Matthew Moyle-Croft Has anyone out there actually done an implentation, across DSL of PD? If you have PLEASE let me know on list/off list/by dead letter drop in a park. Especially interested in CPE etc. --- Please state on list. Many of would like to learn from your experiences. scott
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message <498a40c1.8060...@internode.com.au>, Matthew Moyle-Croft writes:
>
>
> Anthony Roberts wrote:
> >
> >
> > I don't think there's any need for the ISP's routers to advertise all the
> > prefixes they delegate. They'll advertise the /48 or whatever it is, and
> > then delegate chunks out of that.
> >
> My apologies for not being clear:
>
> As I posted just before in reply to MarkA - I'm hoping that for the
> MAJORITY of customers that I can use PD and dynamic /64s (or whatever)
> local to a BRAS.
>
> My FEAR is that people ("customers") are going to start assuming that v6
> means their own static allocation (quite a number are assuming this).
> This means that I have a problem with routing table size etc if I have
> to implement that.
>
> I'm still not convinced though that, given DHCPv6 is going to be a
> reality for DNS assignment etc, that stateless autoconfig is needed and
> thus /64 doesn't have to be the smallest we assign.
All IPv6 address assignments are leases. Whether you get
the address from a RIR, LIR or ISP. The lease may not be
renewed when it next falls due. You may get assigned a
different set of addresses at that point. You should plan
accordingly.
The only difference is the mechanisms used to assign the
leases and the probability that you may have to renumber
when the lease falls due.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Seth Mattinen wrote: Well, it is static, but like most static IP services offerd by an ISP, if you leave you can't take your addresses with you. Even with DSL from AT&T if you move locations you get a different subnet. The issue is multiple POPs in a geographic region where customers could connect to either- if you have those and want them to work in adversity then you've got a problem as you need to allow the static addresses to propogate around. When that number is small then it's not a problem, but when you've got it large scale then you have a routing problem. This is my fear. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 5/02/2009, at 2:35 PM, Seth Mattinen wrote: Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall. A *lot* of these problems we face are conceptual rather than technological. For more, refer to the 69,000 other NANOG posts on the topic. -- Nathan Ward
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On 5/02/2009, at 2:28 PM, Matthew Moyle-Croft wrote:
Anthony Roberts wrote:
I don't think there's any need for the ISP's routers to advertise
all the
prefixes they delegate. They'll advertise the /48 or whatever it
is, and
then delegate chunks out of that.
My apologies for not being clear:
As I posted just before in reply to MarkA - I'm hoping that for the
MAJORITY of customers that I can use PD and dynamic /64s (or
whatever) local to a BRAS.
My FEAR is that people ("customers") are going to start assuming
that v6 means their own static allocation (quite a number are
assuming this). This means that I have a problem with routing
table size etc if I have to implement that.
In my opinion, if they want static, they get business grade services,
and get a /48. Or maybe a /56 over DSL perhaps.
And they pay more for it.
Otherwise they get PD like everybody else. The ability is there *now*
for you to manage this expectation and say to customers that they are
dynamic. Exploit it.
I'm still not convinced though that, given DHCPv6 is going to be a
reality for DNS assignment etc, that stateless autoconfig is needed
and thus /64 doesn't have to be the smallest we assign.
Dynamic PD requires SLAAC, unless your customers have say 30s DHCPv6
lease times on their DHCPv6 servers.
DSL reconnects, gets new IPv6 prefix, sends RA messages internally,
hosts renumber and mark the existing prefix as deprecated until it
expires.
The alternative is waiting for hosts to do a DHCPv6 query to get a new
address. That is sub-optimal.
--
Nathan Ward
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
On Wed, Feb 4, 2009 at 4:16 PM, Patrick W. Gilmore wrote: > I guess I was thinking about v4 modems which do not get a subnet, just an > IP address. If we really are handing out a /64 to each DSL & Cable modem, > then we may very well be recreating the same problem. v4 just gets a single IP address, which is why we need NAT, and apparently NAT is evil. To some extent the /64 can be though of as "just an IP" from the ISP perspective (in the same sense that an IPv4 IP is just a /32 "network"), which has the ability for the CPE to then somehow split it out between multiple hosts - probably using autoconfig (in the same way with IPv4 it's "split up" by the port with NAT). What happens when a customer wants to run multiple networks is something I haven't seen answered yet - with NAT it's easy, but as I said, NAT is apparently evil... On Wed, Feb 4, 2009 at 5:20 PM, Matthew Moyle-Croft wrote: > but my point was that people are starting to assume that v6 WILL mean > static allocations for all customers. By design IPv6 should mean _less_ static allocations than IPv4 - in the event that a client disconnects/reconnects and gets a new /64 then their network *should* automatically handle that fact, with all clients automagically renumbering themselves to the new /64, updating DNS, etc. Local communications won't be impacted as they should be using the link-local address. The bit that isn't clear at the moment is if (and how well) that will actually work in practice. And that brings us back to the good old catch-22 of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE not supporting it because ISP don't... Scott.
Re: Private use of non-RFC1918 IP space
Clarification here: 1/8 was never on the EDS backbone. Was only used locally in one site, as far as I can determine. On Feb 4, 2009, at 7:29 PM, Randy Bush wrote: I see you've never done business with EDS. They've been using 1/8 for over a decade. Also, over the years, I've seen a number of universities and supercomputing facilities number nodes out of 1/8 -- however, those systems are never supposed to see the internet anyway, so they could technically number them however they want. Personally, I've used 1/8 in lab setups. brilliant! i think all my competitors should do that. randy James R. Cutler james.cut...@consultant.com
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Mark Andrews wrote: > In message <498a3ca5.6060...@internode.com.au>, Matthew Moyle-Croft writes: >> Anthony Roberts wrote: >>> On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft >>> wrote: >>> Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6). >>> It's needed to prevent people from NATing in v6, as they'll still want >>> their stuff behind a firewall, and some of them will want subnets. >>> >> Why do we want to prevent people using NAT? If people choose to use >> NAT, then I have no issue with that. >> >> This anti-NAT zealotism is tiring and misplaced. > > NAT's break lots of things and increase the development > costs of every piece of network based software being written. > > If we could get a true accounting of the extra cost imposed > by NAT's I would say it would be in the trillions of dollars. > > NAT's are a necessary evil in IPv4. If every node that > currently communicates to something the other side of a NAT > was to have a global address then we would have already run > out of IPv4 addresses. > > NAT's are not a necessary evil in IPv6. Just stop being > scared to renumber. Addresses are not forever and when you > design for that renumbering get easier and easier. > > For everything else there are alternate solutions. > Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall. A *lot* of these problems we face are conceptual rather than technological. ~Seth
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Matthew Moyle-Croft wrote:
>
>
> Anthony Roberts wrote:
>>
>>
>> I don't think there's any need for the ISP's routers to advertise all the
>> prefixes they delegate. They'll advertise the /48 or whatever it is, and
>> then delegate chunks out of that.
>>
> My apologies for not being clear:
>
> As I posted just before in reply to MarkA - I'm hoping that for the
> MAJORITY of customers that I can use PD and dynamic /64s (or whatever)
> local to a BRAS.
> My FEAR is that people ("customers") are going to start assuming that v6
> means their own static allocation (quite a number are assuming this).
> This means that I have a problem with routing table size etc if I have
> to implement that.
>
Well, it is static, but like most static IP services offerd by an ISP,
if you leave you can't take your addresses with you. Even with DSL from
AT&T if you move locations you get a different subnet.
~Seth
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message <498a3ca5.6060...@internode.com.au>, Matthew Moyle-Croft writes: > Anthony Roberts wrote: > > On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft > > wrote: > > > >> Let's face it - the current v6 assignment rules are to solve a 1990s set > >> of problems. A /64 isn't needed now that we have DHCP(v6). > >> > > > > It's needed to prevent people from NATing in v6, as they'll still want > > their stuff behind a firewall, and some of them will want subnets. > > > Why do we want to prevent people using NAT? If people choose to use > NAT, then I have no issue with that. > > This anti-NAT zealotism is tiring and misplaced. NAT's break lots of things and increase the development costs of every piece of network based software being written. If we could get a true accounting of the extra cost imposed by NAT's I would say it would be in the trillions of dollars. NAT's are a necessary evil in IPv4. If every node that currently communicates to something the other side of a NAT was to have a global address then we would have already run out of IPv4 addresses. NAT's are not a necessary evil in IPv6. Just stop being scared to renumber. Addresses are not forever and when you design for that renumbering get easier and easier. For everything else there are alternate solutions. > >> Setting the idea in people's heads that a /64 IS going to be their own > >> statically is insane and will blow out provider's own routing tables > >> more than is rational. > >> > > > > No larger than their ARP tables are now. > > > And ARP tables are propogated around networks? No, they're local to a > router. > > MMC > > -- > Matthew Moyle-Croft - Internode/Agile - Networks > Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia > Email: m...@internode.com.au Web: http://www.on.net > Direct: +61-8-8228-2909 Mobile: +61-419-900-366 > Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Anthony Roberts wrote:
I don't think there's any need for the ISP's routers to advertise all the
prefixes they delegate. They'll advertise the /48 or whatever it is, and
then delegate chunks out of that.
My apologies for not being clear:
As I posted just before in reply to MarkA - I'm hoping that for the
MAJORITY of customers that I can use PD and dynamic /64s (or whatever)
local to a BRAS.
My FEAR is that people ("customers") are going to start assuming that v6
means their own static allocation (quite a number are assuming this).
This means that I have a problem with routing table size etc if I have
to implement that.
I'm still not convinced though that, given DHCPv6 is going to be a
reality for DNS assignment etc, that stateless autoconfig is needed and
thus /64 doesn't have to be the smallest we assign.
MMC
--
Matthew Moyle-Croft - Internode/Agile - Networks
Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: m...@internode.com.au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: [Update] Re: New ISP to market, BCP 38, and new tactics
On Tue, Feb 3, 2009 at 5:43 PM, Steve Bertrand wrote: > What I was hoping for (even though I'm testing something that I know > won't work) is that I can break something so I could push v4 traffic > over a v6-only core. > > Is there _any_ way to do this (other than NAT/tunnel etc)? If you can push v4 over it (other than through a NAT/tunnel/etc.), then it's not a v6-only core :-) The real question is whether you're going to route natively in v4, or do a v4-in-v6 tunnel of some sort, or a v4-in-Layer2-in-v6 tunnel of some sort, or do NAT, or use MPLS as a Layer 2ish core. If you're doing MPLS, you'll need to figure out if you can run _it_ with purely v6 gear supporting it, or whether you'll need to run v4 to make all of your MPLS vendors happy, but that doesn't need to be publicly routable v4 carrying the entire Internet's routing tables on it; you can leave the Internet inside a large MPLS VPN if you want. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 05 Feb 2009 11:41:01 +1030, Matthew Moyle-Croft wrote: > And ARP tables are propogated around networks? No, they're local to a > router. I don't think there's any need for the ISP's routers to advertise all the prefixes they delegate. They'll advertise the /48 or whatever it is, and then delegate chunks out of that.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Mark Andrews wrote: Assign the prefixes using PD and use aggregate routes out side of the pop. IPv6 nodes are designed to be renumbered. Use the technology. Stop thinking IPv4 and start thinking IPv6. IPv6 is not just IPv4 with bigger addresses. Currently with v4 I have one (majority) of customers where they have dynamic addresses. For those I'm happy to use PD - but my point was that people are starting to assume that v6 WILL mean static allocations for all customers. This is my fear, is NOT being able to use PD for the "residential grade" customers. Having to provide static allocations is a problem if I have multiple POPs in a geographic region as I can't summarise and get the redundancy I want. (If I commit to a customer they have a static range then I can't easily change it on them - esp if they've done things like used the addresses statically in DNS etc as our customers are want to do). Has anyone out there actually done an implentation, across DSL of PD? If you have PLEASE let me know on list/off list/by dead letter drop in a park. Especially interested in CPE etc. Regards, Matthew Mark -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Anthony Roberts wrote: On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft wrote: Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6). It's needed to prevent people from NATing in v6, as they'll still want their stuff behind a firewall, and some of them will want subnets. Why do we want to prevent people using NAT? If people choose to use NAT, then I have no issue with that. This anti-NAT zealotism is tiring and misplaced. Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. No larger than their ARP tables are now. And ARP tables are propogated around networks? No, they're local to a router. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 05 Feb 2009 11:08:44 +1030, Matthew Moyle-Croft wrote: > > Let's face it - the current v6 assignment rules are to solve a 1990s set > of problems. A /64 isn't needed now that we have DHCP(v6). It's needed to prevent people from NATing in v6, as they'll still want their stuff behind a firewall, and some of them will want subnets. > Setting the idea in people's heads that a /64 IS going to be their own > statically is insane and will blow out provider's own routing tables > more than is rational. No larger than their ARP tables are now.
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
In message <498a3514.1050...@internode.com.au>, Matthew Moyle-Croft writes: > Patrick W. Gilmore wrote: > > > > And before anyone says "there are 281474976710656 /48s!", just > > remember your history. I was not there when v4 was spec'ed out, but I > > bet when someone said "four-point-two BILLION addresses", someone else > > said "no $...@#%'ing way we will EVER use THAT many" > Let's face it - the current v6 assignment rules are to solve a 1990s set > of problems. A /64 isn't needed now that we have DHCP(v6). Setting > the idea in people's heads that a /64 IS going to be their own > statically is insane and will blow out provider's own routing tables > more than is rational. (Think of the processing overhead of all the > DSL/Cable customers going up and down). This is going to be far more of > an issue and drive network design than a minor blow out in the v6 > routing table. Assign the prefixes using PD and use aggregate routes out side of the pop. IPv6 nodes are designed to be renumbered. Use the technology. Stop thinking IPv4 and start thinking IPv6. IPv6 is not just IPv4 with bigger addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: Private use of non-RFC1918 IP space
> I see you've never done business with EDS. They've been using 1/8 for > over a decade. Also, over the years, I've seen a number of universities > and supercomputing facilities number nodes out of 1/8 -- however, those > systems are never supposed to see the internet anyway, so they could > technically number them however they want. Personally, I've used 1/8 in > lab setups. brilliant! i think all my competitors should do that. randy
Re: Private use of non-RFC1918 IP space (IPv6-MW)
On Wed, 4 Feb 2009 15:56:44 -0800, Scott Howard wrote: > On Mon, Feb 2, 2009 at 9:30 PM, > Anthony Roberts wrote: > >> It has been my experience that when you give someone a huge address space >> to play with (eg 10/8), they start doing things like using bits in the >> address as flags for things. Suddenly you find yourself using a prefix >> that should enough for a decent sized country in a half-rack. > > Which is, of course, a core design philosophy for IPv6. Stateless > autoconfig > relies on the fact that each network will be allocated 2^64 address. I'm actually pretty happy about /64's, they take away all the hand-wringing over how big a network should be, and they make manually configured server addresses easier to remember through the use of big regions of 0s. I was thinking more about wasting prefix bits. -Anthony
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Patrick W. Gilmore wrote: And before anyone says "there are 281474976710656 /48s!", just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $...@#%'ing way we will EVER use THAT many" Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. (Think of the processing overhead of all the DSL/Cable customers going up and down). This is going to be far more of an issue and drive network design than a minor blow out in the v6 routing table. As Neil Finn of Split Enz fame once wrote: History never repeats, I tell myself before I go to sleep. Followed on the same album by a song called "My Mistake". MMC (Who's trying to implement v6 native for DSL customers but finds that the world doesn't have useable solutions yet for DSL CPE, BRAS, IPv6 allocation etc and doesn't look like it will for a while). -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
Patrick W. Gilmore wrote: > On Feb 4, 2009, at 7:08 PM, Seth Mattinen wrote: >> Patrick W. Gilmore wrote: >>> > >>> Second, where did you get 4 users per /64? Are you planning to hand >>> each cable modem a /64? >> >> >> That was the generally accepted subnet practice last time I had a >> discussion about it on the ipv6-ops list. I'm not an ISP, but I have a >> /48 and each subnet is a /64. Some devices will refuse to work if you >> subnet smaller than a /64. (Yes, poorly designed, etc.) > > I Am Not An ISP either. :) > > I guess I was thinking about v4 modems which do not get a subnet, just > an IP address. If we really are handing out a /64 to each DSL & Cable > modem, then we may very well be recreating the same problem. > > And before anyone says "there are 281474976710656 /48s!", just > remember your history. I was not there when v4 was spec'ed out, but I > bet when someone said "four-point-two BILLION addresses", someone else > said "no $...@#%'ing way we will EVER use THAT many" > Ah, but RFC 760, before 791, did assume "more than 253 networks? Nahhh..."
RE: Private use of non-RFC1918 IP space (IPv6-MW)
> > IPv4-style utilization ratios do make some sense under IPv6, but not > > at the > > address level - only at the network level. > > First, it was (mostly) a joke. > > Second, where did you get 4 users per /64? Are you planning to hand > each cable modem a /64? > At the least. Some would say a /56 is more appropriate. So, one /64 for your desktop and one /64 for your open wireless. :-) Mike PGP.sig Description: PGP signature
v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Feb 4, 2009, at 7:08 PM, Seth Mattinen wrote: Patrick W. Gilmore wrote: Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64? That was the generally accepted subnet practice last time I had a discussion about it on the ipv6-ops list. I'm not an ISP, but I have a /48 and each subnet is a /64. Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.) I Am Not An ISP either. :) I guess I was thinking about v4 modems which do not get a subnet, just an IP address. If we really are handing out a /64 to each DSL & Cable modem, then we may very well be recreating the same problem. And before anyone says "there are 281474976710656 /48s!", just remember your history. I was not there when v4 was spec'ed out, but I bet when someone said "four-point-two BILLION addresses", someone else said "no $...@#%'ing way we will EVER use THAT many" -- TTFN, patrick
Re: Private use of non-RFC1918 IP space (IPv6-MW)
Patrick W. Gilmore wrote: > On Feb 4, 2009, at 6:56 PM, Scott Howard wrote: >> On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore >> wrote: >> >>> Except the RIRs won't give you another /48 when you have only used one >>> trillion IP addresses. >> >> Of course they will! A /48 is only the equivalent of 65536 "networks" >> (each >> network being a /64). Presuming that ISPs allocate /64 networks to each >> connected subscriber, then a /48 is only 65k subscribers, or say around a >> maximum of 200k IP addresses in use at any one time (presuming no NAT >> and an >> average of 3-4 IP-based devices per subscriber) >> >> IPv4-style utilization ratios do make some sense under IPv6, but not >> at the >> address level - only at the network level. > > First, it was (mostly) a joke. > > Second, where did you get 4 users per /64? Are you planning to hand > each cable modem a /64? > That was the generally accepted subnet practice last time I had a discussion about it on the ipv6-ops list. I'm not an ISP, but I have a /48 and each subnet is a /64. Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.) ~Seth
Re: Private use of non-RFC1918 IP space (IPv6-MW)
On Feb 4, 2009, at 6:56 PM, Scott Howard wrote: On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Of course they will! A /48 is only the equivalent of 65536 "networks" (each network being a /64). Presuming that ISPs allocate /64 networks to each connected subscriber, then a /48 is only 65k subscribers, or say around a maximum of 200k IP addresses in use at any one time (presuming no NAT and an average of 3-4 IP-based devices per subscriber) IPv4-style utilization ratios do make some sense under IPv6, but not at the address level - only at the network level. First, it was (mostly) a joke. Second, where did you get 4 users per /64? Are you planning to hand each cable modem a /64? -- TTFN, patrick
Re: Private use of non-RFC1918 IP space (IPv6-MW)
On Mon, Feb 2, 2009 at 9:30 PM, Anthony Roberts wrote: > It has been my experience that when you give someone a huge address space > to play with (eg 10/8), they start doing things like using bits in the > address as flags for things. Suddenly you find yourself using a prefix > that should enough for a decent sized country in a half-rack. Which is, of course, a core design philosophy for IPv6. Stateless autoconfig relies on the fact that each network will be allocated 2^64 address. On Mon, Feb 2, 2009 at 9:35 PM, Patrick W. Gilmore wrote: > Except the RIRs won't give you another /48 when you have only used one > trillion IP addresses. Of course they will! A /48 is only the equivalent of 65536 "networks" (each network being a /64). Presuming that ISPs allocate /64 networks to each connected subscriber, then a /48 is only 65k subscribers, or say around a maximum of 200k IP addresses in use at any one time (presuming no NAT and an average of 3-4 IP-based devices per subscriber) IPv4-style utilization ratios do make some sense under IPv6, but not at the address level - only at the network level. Scott.
Re: Private use of non-RFC1918 IP space
--On onsdag, onsdag 4 feb 2009 17.44.20 -0500 Ricky Beam wrote: > On Tue, 03 Feb 2009 20:29:36 -0500, Skeeve Stevens > wrote: >> I agree... I'd love to know where they got that from... who even wrote >> it? > > I see you've never done business with EDS. They've been using 1/8 for > over a decade. Also, over the years, I've seen a number of universities > and supercomputing facilities number nodes out of 1/8 -- however, those > systems are never supposed to see the internet anyway, so they could > technically number them however they want. Personally, I've used 1/8 in > lab setups. Last time I built a supercomputer (as in a cluster of run-of-the-mill servers) RIPE gave us a /21 -- I wanted a /20 for the expected upgrade but was told I had to reapply. The compute nodes need to read files from AFS from CERN or another university, so NAT'ing them is so not an option. -- Måns NilssonM A C H I N A Sign my PETITION. pgpRAYgcPsBjH.pgp Description: PGP signature
Re: Database backed DNS Management Solutions
Steven Crandell wrote: > I'm a long time BIND user and recent convert to PowerDNS. > I considered BIND-DLZ briefly but found that I wasn't excited about the DB > retro-fit on a piece of software that was previously very much meant to live > in the world of flat files. > My initial intent was to try PowerDNS first and then give BIND-DLZ a test > drive also, but I never got around to BIND-DLZ given how well PowerDNS > performed. > > My only beef with PDNS is the inability to use master-slave replication to > hosts that are not listed as type NS. > This is by design but it nevertheless got in my way. > I've since just set all domains to use native replication (e.g. db backend > repliciation, Postgres/Slony in this instance) and absolutely could not be > happier with the results. > > The amount of time I spend managing DNS has been reduced to almost nothing > given how easily I can script my large operations. > Still it pays to be wise: Use transactions!! > Always, always, *always* use a transaction-aware database with PowerDNS. That said, I too am a happy user of PowerDNS using native database replication. The recent January 27 release added a lot of good stuff. ~Seth
Re: Private use of non-RFC1918 IP space
On Tue, 03 Feb 2009 20:29:36 -0500, Skeeve Stevens wrote: I agree... I'd love to know where they got that from... who even wrote it? I see you've never done business with EDS. They've been using 1/8 for over a decade. Also, over the years, I've seen a number of universities and supercomputing facilities number nodes out of 1/8 -- however, those systems are never supposed to see the internet anyway, so they could technically number them however they want. Personally, I've used 1/8 in lab setups. --Ricky
Re: Database backed DNS Management Solutions
I'm a long time BIND user and recent convert to PowerDNS. I considered BIND-DLZ briefly but found that I wasn't excited about the DB retro-fit on a piece of software that was previously very much meant to live in the world of flat files. My initial intent was to try PowerDNS first and then give BIND-DLZ a test drive also, but I never got around to BIND-DLZ given how well PowerDNS performed. My only beef with PDNS is the inability to use master-slave replication to hosts that are not listed as type NS. This is by design but it nevertheless got in my way. I've since just set all domains to use native replication (e.g. db backend repliciation, Postgres/Slony in this instance) and absolutely could not be happier with the results. The amount of time I spend managing DNS has been reduced to almost nothing given how easily I can script my large operations. Still it pays to be wise: Use transactions!! I've also been getting slightly better query response times with PDNS than I did with BIND for what it's worth. -s On Wed, Feb 4, 2009 at 8:10 AM, Michele Neylon :: Blacknight < mich...@blacknight.ie> wrote: > >> > We developed our own PHP / MySQL system that holds all the records before > writing out zonefiles and updates to BIND. We've been using it for several > years and it works well :) > > > Mr Michele Neylon > Blacknight Solutions > Hosting & Colocation, Brand Protection > http://www.blacknight.com/ > http://blog.blacknight.com/ > Intl. +353 (0) 59 9183072 > US: 213-233-1612 > UK: 0844 484 9361 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Fax. +353 (0) 1 4811 763 > --- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > >
Re: Database backed DNS Management Solutions
We developed our own PHP / MySQL system that holds all the records before writing out zonefiles and updates to BIND. We've been using it for several years and it works well :) Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
