Re: v6 subnet size for DSL & leased line customers
On Dec 24, 2007, at 9:43 PM, Kevin Loch wrote: Iljitsch van Beijnum wrote: On 24 dec 2007, at 20:00, Kevin Loch wrote: RA/Autoconf won't work at all for some folks with deployed server infra, That's just IPv4 uptightness. As long as you don't change your MAC address you'll get the same IPv6 address every time, this works fine for servers unless you need a memorable address. BTW, I don't know anyone who uses DHCP for their servers. Hopefully vrrpv6 will work with RA turned completely off. With router advertisements present you don't need VRRP because you have dead neighbor detection. And that helps the hosts on the same l2 segment that need different gateways how? Or hosts with access to multiple l2 segments with different gateways? I think the point is that RA and VRRPv6 are not designed to depend on each other in any way. While you can certainly run both on any given segment, it is hard to imagine many cases where one would want to do so. In places where all you need is to know a valid gateway that can do the right thing with your packets, RA is probably the right solution. This, generally, turns out to be the vast majority of LAN segments. Clearly, RA is intended only for scenarios where a gateway is a gateway is a gateway. In places where you need tighter control over the usage of various gateways on a common L2 segment, VRRP probably makes more sense. However, as things currently stand, that means static routing configuration on the host since for reasons passing understanding, DHCP6 specifically won't do gateway assignment. I don't know the state of the current VRRP6 draft or protocol, but, I can't imagine what would be left in VRRP6 if it couldn't be statically configured without RA. If that's the case, then, what would it possibly do, exactly, that would be different from RA without VRRP? Owen
Re: v6 subnet size for DSL & leased line customers
Iljitsch van Beijnum wrote: On 24 dec 2007, at 20:00, Kevin Loch wrote: RA/Autoconf won't work at all for some folks with deployed server infra, That's just IPv4 uptightness. As long as you don't change your MAC address you'll get the same IPv6 address every time, this works fine for servers unless you need a memorable address. BTW, I don't know anyone who uses DHCP for their servers. Hopefully vrrpv6 will work with RA turned completely off. With router advertisements present you don't need VRRP because you have dead neighbor detection. And that helps the hosts on the same l2 segment that need different gateways how? Or hosts with access to multiple l2 segments with different gateways? RA is a shotgun. All hosts on a segment get the same gateway. I have no idea what a host on multiple segments with different gateways would do. Hosting environments can get complex thanks to customer requirements and baggage from previous migrations. Load balancer and VPN configurations are common culprits but there are also cases where servers need different gateways for routing policy reasons. All of this is easily accommodated with static gateways and the redundancy provided by vrrpv4. Please don't take that away from us. Migration to v6 will be difficult enough without subtracting functionality from our existing tools. Other than that I look forward to seeing what wonderful things we can do with RA to simplify things in cases where shotgun == ok. - Kevin
Re: v6 subnet size for DSL & leased line customers
On Sun, 23 Dec 2007, Randy Bush wrote: Mohacsi Janos wrote: There plenty of organisation who has a dedicated team/person for network management (routers, switches etc.), while another team/person for system management (dhcp, servers etc.). So configuring DHCPv6 requires cooperation which takes time, but users are complaining so, what problems are there with dhcpv6 that differ from those we have experienced with dchpv4? what would be good to know before trying to deploy it? do organizations you know prefer autoconf or dhcpv6? and why? Actually we are using stateless form of DHCPv6 to announce DNS servers with autoconf + static address comfiguration for servers. This is satisfactory for a small organisation like us (less than 40 persons). We are testing DHCPv6 also. For a larger organisation (>1000 computer) I will ask my colleagues about their DHCPv6 experiences Best Regards, Janos Mohacsi
Re: v6 subnet size for DSL & leased line customers
On 24 dec 2007, at 20:00, Kevin Loch wrote: RA/Autoconf won't work at all for some folks with deployed server infra, That's just IPv4 uptightness. As long as you don't change your MAC address you'll get the same IPv6 address every time, this works fine for servers unless you need a memorable address. BTW, I don't know anyone who uses DHCP for their servers. Hopefully vrrpv6 will work with RA turned completely off. With router advertisements present you don't need VRRP because you have dead neighbor detection.
Re: v6 subnet size for DSL & leased line customers
Christopher Morrow wrote: On Dec 22, 2007 12:23 PM, Ross Vandegrift <[EMAIL PROTECTED]> wrote: On Fri, Dec 21, 2007 at 01:33:15PM -0500, Deepak Jain wrote: For example... Within one's own network (or subnet if you will) we can absorb all the concepts of V4 today and have lots of space available. For example... for the DMZ of a business... Why not give them 6 bits (/122?) are we anticipating topology differences UPSTREAM from the customers that can take advantage of subnet differences between /64 and /56 ? I am confused on this point as well. IPv6 documents seem to assume that because auto-discovery on a LAN uses a /64, you always have to use a /64 global-scope subnet. I don't see any technical issues that require this though. ICMPv6 is capable of passing info on prefixes of any length - prefix length is a plain old 8bit field. Uhm, so sure the spec might be able to do something different than /64 but most equipment I've used only does auto-conf if the prefix is a /64 :( Somewhere along the path to ipng we got reverted to classful addressing again :( I think this is the point I was trying to make. Just because we have "so many bits" now... why does the equipment/software need to get "stupider" again? Are we going to have an IPv6 CIDR initiative again (15 years from now) to recover all of that wasted space from "early" allocations).. Merry Christmas, and junk. Deepak
Re: v6 subnet size for DSL & leased line customers
Christopher Morrow wrote: RA/Autoconf won't work at all for some folks with deployed server infra, all they want is a method to get a static addr on a box and route properly. Perhaps RA gets them the 'route properly' part easily enough but I can imagine places where that is even turned off. I think it would be great to be able to do hybrids with RA for other situations where a shotgun approach is ok but I do not think we will want to use that in server environments. Hopefully vrrpv6 will work with RA turned completely off. - Kevin
Re: v6 subnet size for DSL & leased line customers
Scott Weeks wrote: Disclaimer: I'm still very much an IPv6 wussie... :-) - But even in 2000 the policy was and still is: /128 for really a single device /64 if you know for sure that only one single subnet will ever be allocated. /48 for every other case (smart bet, should be used per default) -- I work on a network with 100K+ DSL folks and 200+ leased line customers, plus some other stuff. The leased line customers are increasing dramatically. I should plan for a /64 for every DSL customer and a /48 for every leased line customer I expect over the next 5-7 years? scott Same disclaimer as above. But perhaps thats a benefit, allowing the landscape forest view instead of the tree one. Seems like everything good and desirable in ipv6 was backported to ipv4, including router advertisements (which nobody uses, since DHCP [yes dhcp can/could be made redundant] is far far preferred, even by SOHO vendors). All except the 4 x bitspace. If it hasnt been backported after all this time, its likely either undoable or unusable. Since its quite likely that a minimum 50 year lifetime for ipv4 looks to be in the cards, judging by bitspace, ipv6 should be engineered for 200 (or 50 to the 4th which makes 125000). One would suppose that the way to do this is to do as much as is neccessary to comfortably move the world onto it AND NO MORE. We are not prophets. We dont even know how many prefixes the average router will be able to handle in 10 years (considering that a maxed out pc-as-a-router can handle millions more than the nice expensive 7600), let alone 50. So the first thing we do is: Make it as big for ISP's as ipv4 was for end users, by assigning /32 prefixes, minus all the special purpose carvings. To make things simple, a 4 byte AS should come with a /32. Brilliant. We have forward ported ipv4 scalability onto ipv6. For what? So that end users can have nanotech networks? It goes without saying that I will want my nanotech network(s) firewalled (and natted for good measure). Autoconfiguration doesnt require 64 bits. We have autoconfig for ipv4, it appears to only need 16. As stated, we dont want people to be taking their /64's with them as they change ISP's, so imbuing all this uniqueness and matching it with their global id's and telephone numbers is just asking for trouble. Unless the whole world becomes an ISP. Presto, address shortage unless massive depopulation occurs over the next couple hundred years. We should not pretend to be building an allocation structure that will not simultaneously satisify uniqueness, portability and scalability for the next hundred years or so when we clearly are not. Whats the current state with PI in ipv6? How often will it change? We could have reserved 90% of the first 32 bits, use the next 32 bits to assign to ISP's /64 bits, and allow the ISP's to assign an internet worth of customer their own internet. Tiered routing? Geo-location routing? All easily made available with another bit or two from the first /32. Oh and the whole protocol is still useless, since proper connectivity to the ipv4 network without an ipv4 stack seems to be somewhat non standard. Obviously, nobody rolling out ipv6 due to address shortage is going to tolerate that, and interop strategies will be used, standard or not. Expect the interop strategy to be the one with the lowest network resistance. Thats nat. IPv6 is a textbook second system syndrome. We could have all been on it already without the dozens of super-freighters attached to the 128bit tugboat. Joe
Re: v6 subnet size for DSL & leased line customers
Joe Greco wrote: >> It's likely that the device may choose to nat when they cannot obtain a >> prefix... pd might be desirable but if you can't then the alternative is >> easy. > > I thought we were all trying to discourage NAT in IPv6. You/we are... Which is why you really need PD, and cpe needs to be able to hand out /64s on request to downstream devices. Not surprisingly that will drive subnetting in the home. presently, plugging in more gateway/router devices results in multiple layers of nat and huge amounts of unnecessary complexity in the home network. > Clearly, NAT > solves the problem ... while introducing 1000 new ones. :-/ Sure, we don't have a reasonable mechanism for ipv4 devices to pull address space out of thin air. We do have one in ipv6. This is a problem that equipment makers (as much as randy hates them) will have to address. It doesn't take much imagination to figure out how they will address it given a lack of alternatives. > ... JG
Re: v6 subnet size for DSL & leased line customers
> I thought we were all trying to discourage NAT in IPv6. Clearly, NAT > solves the problem ... while introducing 1000 new ones. :-/ Clearly some have been trying to discourage NAT in IPv6 ensuring there'll be a 1000 problems if anyone tries. > I mean, yeah, it'd be great if we could mandate /48 ... but I just can't > see it as likely to happen. If people are supposed to have a /48 then the allocation rules should say that's what they will get. It may be xmas but it's not wise to rely on the benevolence of ISPs brandon
Re: v6 subnet size for DSL & leased line customers
"Well, you say we need to spend more money every year on address space. Right now we're paying $2,250/year for our /32, and we're able to serve 65 thousand customers. You want us to start paying $4,500/year, but Bob tells me that we're wasting a lot of our current space, and if we were to begin allocating less space to customers [aside: /56 vs /48], that we could actually serve sixteen million users for the same cash. Is there a compelling reason that we didn't do that from the outset?" Right... Let's look at this in detail: /48 per customer == 65,536 customers at $2,250 == $0.03433/customer /56 per customer == 16,777,216 customers at $2,250 == $0.00013/customer So, total savings per customer is $0.0342/customer _IF_ you have 16,777,216 customers. On the other hand, sir, for those customers who need more than 256 subnets, we're running the risk of having to assign them multiple noncontiguous prefixes. Although the cost of doing so is not readily apparent, each router has a limit to the number of prefixes that can be contained in the routing table. The cost of upgrading all of our routers later probably far exceeds the $0.03 per customer that we would save. Really, in general, I think that the place to look for per-customer savings opportunities would be in places where we have a potential recovery greater than $0.03 per customer. This discussion is getting really silly; the fact of the matter is that this /is/ going to happen. To pretend that it isn't is simply naive. How high are your transit&equipment bills again, and how are you exactly charging your customers? ah, not by bandwidth usage, very logical! Perhaps end-user ISP's don't charge by bandwidth usage... True, but, they don't, generally, charge by the address, either. Usually, they charge by the month. If you can't cover $0.03/year/ customer for address space in your monthly fees, then, raise your monthly fee by $0.05. I'm betting your customers won't care. As an enduser I would love to pay the little fee for IP space that the LIR (ISP in ARIN land) pays to the RIR and then simply pay for the bandwidth that I am using + a little margin so that they ISP also earns some bucks and can do writeoffs on equipment and personnel. Sure, but that's mostly fantasyland. The average ISP is going to want to monetize the variables. You want more bandwidth, you pay more. You want more IP's, you pay more. This is one of the reasons some of us are concerned about how IPv6 will /actually/ be deployed ... quite frankly, I would bet that it's a whole lot more likely that an end-user gets assigned a /64 than a /48 as the basic class of service, and charge for additional bits. If we are lucky, we might be able to s/64/56/. I mean, yeah, it'd be great if we could mandate /48 ... but I just can't see it as likely to happen. I'm betting that competition will drive the boundary left without additional fees. After all, if you're only willing to dole out /64s and your competitor is handing out /56 for the same price, then all the customers that want multiple subnets are going to go to your competitor. The ones that want /48s will find a competitor that offers that. That's how the real world works. I remember having to repeatedly involve senior management in rejecting requests for /24s from customers who could not justify them because our sales people at Exodus kept promising them. The sales people continuously suggested that our competitors were offering everyone /24s and that they had to do that to win the deals. OTOH, "Raw bandwidth communications" seems to want to charge bandwidth utilization not actually based on the bandwidth utilized, but, the number of IP addresses routed. They are not my ISP for that reason. Different providers have different business models. Consumers will find the provider with the business model that best fits their needs. That's the way it works in the real world. So, the point is, as engineers, let's not be completely naive. Yes, we /want/ end-users to receive a /56, maybe even a /48, but as an engineer, I'm going to assume something more pessimistic. If I'm a device designer, I can safely do that, because if I don't assume that a PD is going to be available and plan accordingly, then my device is going to work in both cases, while the device someone who has relied on PD is going to break when it isn't available. Assuming that PD is available is naive. However, assuming it is not is equally naive. The device must be able to function in both circumstances if possible, or, should handle the case where it can't function in a graceful and informative manner. Owen
Re: v6 subnet size for DSL & leased line customers
> Joe Greco wrote: > [..] > > Okay, here, let me make it reaaally simple. > > Yes, indeed lets make it reaaally simple for you: > > > If your ISP has been delegated a /48 (admittedly unlikely, but possible= > ) > > for $1,250/year, and they assign you a /56, their cost to provide that > > space is ~$5. They can have 256 such customers. > > Fortunately ISP's get their space per /32 and up based on how much they > can justify, which is the amount of customers they have. > > As such for a /32 single /48 is only (x / 65k) =3D like 20 cents or so? > And if you are running your business properly you will have more clients > and the price will only go down and down and down. > > Really (or should I write "reaaally" to add force?) if you > as an ISP are unable to pay the RIR fees for that little bit of address > space, then you definitely have bigger problems as you won't be able to > pay the other bills either. There's a difference between "unable to pay the RIR fees" and "do not deem any business value in spending the money." Engineers typically feel that businesses should be ready and willing to spend more money for reasons that the average business person won't care about. Pretend I'm your CFO. Explain the value proposition to me. Here's the (slightly abbreviated) conversation. "Well, you say we need to spend more money every year on address space. Right now we're paying $2,250/year for our /32, and we're able to serve 65 thousand customers. You want us to start paying $4,500/year, but Bob tells me that we're wasting a lot of our current space, and if we were to begin allocating less space to customers [aside: /56 vs /48], that we could actually serve sixteen million users for the same cash. Is there a compelling reason that we didn't do that from the outset?" This discussion is getting really silly; the fact of the matter is that this /is/ going to happen. To pretend that it isn't is simply naive. > How high are your transit&equipment bills again, and how are you exactly > charging your customers? ah, not by bandwidth usage, very logical! Perhaps end-user ISP's don't charge by bandwidth usage... > As an enduser I would love to pay the little fee for IP space that the > LIR (ISP in ARIN land) pays to the RIR and then simply pay for the > bandwidth that I am using + a little margin so that they ISP also earns > some bucks and can do writeoffs on equipment and personnel. Sure, but that's mostly fantasyland. The average ISP is going to want to monetize the variables. You want more bandwidth, you pay more. You want more IP's, you pay more. This is one of the reasons some of us are concerned about how IPv6 will /actually/ be deployed ... quite frankly, I would bet that it's a whole lot more likely that an end-user gets assigned a /64 than a /48 as the basic class of service, and charge for additional bits. If we are lucky, we might be able to s/64/56/. I mean, yeah, it'd be great if we could mandate /48 ... but I just can't see it as likely to happen. > For some magic reasons though(*), it seems to be completely ludacrist to > do it this way, even though it would make the bill very clear and it > would charge the right amount for the right things and not some > arbitrary number for some other arbitrary things and then later > complaining that people use too much bandwidth because they use > bittorrent and other such things. For the cable folks: make upstream > bandwidth more pricey per class than downstream, problem of > heavy-uploaders solved as they get charged. Sure, but that's how the real world works. The input from engineering folks is only one small variable in the overall scheme of things. It is a /mistake/ to assume that cost-recovery must be done on a direct basis. There's a huge amount of business value in being able to say "unlimited(*) Internet service for $30/mo!" The current offerings in many places should outline this clearly. So, the point is, as engineers, let's not be completely naive. Yes, we /want/ end-users to receive a /56, maybe even a /48, but as an engineer, I'm going to assume something more pessimistic. If I'm a device designer, I can safely do that, because if I don't assume that a PD is going to be available and plan accordingly, then my device is going to work in both cases, while the device someone who has relied on PD is going to break when it isn't available. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: v6 subnet size for DSL & leased line customers
> It's likely that the device may choose to nat when they cannot obtain a > prefix... pd might be desirable but if you can't then the alternative is > easy. I thought we were all trying to discourage NAT in IPv6. Clearly, NAT solves the problem ... while introducing 1000 new ones. :-/ ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: v6 subnet size for DSL & leased line customers
Hi Jeroen, On 24/12/2007, at 6:07 PM, Jeroen Massar wrote: Joe Greco wrote: [..] Okay, here, let me make it reaaally simple. Yes, indeed lets make it reaaally simple for you: If your ISP has been delegated a /48 (admittedly unlikely, but possible) for $1,250/year, and they assign you a /56, their cost to provide that space is ~$5. They can have 256 such customers. How high are your transit&equipment bills again, and how are you exactly charging your customers? ah, not by bandwidth usage, very logical! Not my bandwidth usage? Ha. Ha. Haha. Ha. Fortunately a /32 allocation was free from APNIC with our existing membership tier. Regards, Trent Australia
Re: v6 subnet size for DSL & leased line customers
Joe Greco wrote: [..] > Okay, here, let me make it reaaally simple. Yes, indeed lets make it reaaally simple for you: > If your ISP has been delegated a /48 (admittedly unlikely, but possible) > for $1,250/year, and they assign you a /56, their cost to provide that > space is ~$5. They can have 256 such customers. Fortunately ISP's get their space per /32 and up based on how much they can justify, which is the amount of customers they have. As such for a /32 single /48 is only (x / 65k) = like 20 cents or so? And if you are running your business properly you will have more clients and the price will only go down and down and down. Really (or should I write "reaaally" to add force?) if you as an ISP are unable to pay the RIR fees for that little bit of address space, then you definitely have bigger problems as you won't be able to pay the other bills either. How high are your transit&equipment bills again, and how are you exactly charging your customers? ah, not by bandwidth usage, very logical! As an enduser I would love to pay the little fee for IP space that the LIR (ISP in ARIN land) pays to the RIR and then simply pay for the bandwidth that I am using + a little margin so that they ISP also earns some bucks and can do writeoffs on equipment and personnel. For some magic reasons though(*), it seems to be completely ludacrist to do it this way, even though it would make the bill very clear and it would charge the right amount for the right things and not some arbitrary number for some other arbitrary things and then later complaining that people use too much bandwidth because they use bittorrent and other such things. For the cable folks: make upstream bandwidth more pricey per class than downstream, problem of heavy-uploaders solved as they get charged. Greets, Jeroen (* = then again I don't have an mba or something like that so I prolly miss out an all kinds of important factors why people have to make it so complex) signature.asc Description: OpenPGP digital signature
