RE: v6 subnet size for DSL leased line customers
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leo Bicknell Sent: Thursday, December 27, 2007 8:51 AM To: North American Network Operators Group Subject: Re: v6 subnet size for DSL leased line customers In a message written on Thu, Dec 27, 2007 at 11:27:13AM +0100, Iljitsch van Beijnum wrote: 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information. I would note, it's not too late to fix these problems. We don't have wide spread IPv6 deployment yet, and I can't imagine it's all that hard to send a default gateway in DHCPv6, for example. -- Someone earlier threw out an offhand 'preferred gateway' DHCPv6 parameter as a possibility. This is actually a nifty idea... Hey, you there, use potential gateways in the following order! It has the same utility and simplicity that MX records do. Jamie
Re: v6 subnet size for DSL leased line customers
Thus spake Simon Lyall [EMAIL PROTECTED] On Wed, 2 Jan 2008, Deepak Jain wrote: Is there anything inherently harmful with suggesting that filtering at RIR boundaries should be expected, but those that accept somewhat more lenient boundaries are nice guys??? When the nice guys run out of resources, they can filter at RIR boundaries and say they are doing so as a security upgrade :_). So how would this work for large companies? In theory multinationals like Morgan Stanley, Wall-Mart or HSBC should only get at most a /48 from each RIR. In what theory? They'd get at _minimum_ a /48 from each RIR that has approved PIv6. If they needed more, they merely have to fill out the appropriate paperwork showing justification. If they operate in regions where the RIR hasn't approved PIv6, they'd route around the failure there and use space assigned by other RIRs. (Not saying I approve of that, but it's reality.) Currently ARIN is approving all requests for more than a /48 since there is no definition of what justify means in that context. Ebay, which is hardly the size of the companies you listed, got a /41. That obviously needs fixing, but the problem is the opposite of the one you seem to be theorizing. How should they handle region offices, Especially mutihomed ones? Announce their prefix from all locations, with more-specifics for TE purposes. Presumably their upstreams would carry the more-specifics since they're being paid to, but folks further away would filter them and only see the covering aggregate, which is good enough. (Note this assumes they have an internal network; if they didn't, each disconnected part would be a site and qualify for a /48 on its own. That's a suboptimal solution, though, for reasons too numerous to list.) S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: v6 subnet size for DSL leased line customers
On 30 dec 2007, at 21:33, Scott Weeks wrote: I haven't requested anything yet. That's why I came to you folks. To learn and then get busy on it. Thanks for your top-down and bottom-up idea. I will probably also intersperse /56s in between allocations as well; filling them in later if it ever gets to that. If you know that you're going to need more than a /32, be sure to ask ARIN for more than the default. But these things are almost impossible to get right the first time, so don't sweat it if you have to come back for more later. There are more than 8 prefixes per AS for IPv4. One prefix per AS for IPv6 is a laudable goal, but it's not a huge deal if it's more like 2.
Re: v6 subnet size for DSL leased line customers
On 31 dec 2007, at 1:24, Mark Smith wrote: Another idea would be to give each non-/48 customer the first /56 out of each /48. Right, so you combine the downsides of both approaches. It doesn't work when ARIN does it: * 24.122.32.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.48.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.64.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.80.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.96.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.112.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.128.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.144.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.160.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.176.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.192.0/19 4.68.1.166 0 0 3356 6453 11290 i * 24.122.224.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.240.0/20 4.68.1.166 0 0 3356 6453 11290 i And it's unlikely to work here: for those standard size blocks, you really don't want any per-user config: you want those to be assigned automatically. But for the /48s you do need per-user config, if only that this user gets a /48. So these two block sizes can't realistically come from the same (sub-) range.
Re: v6 subnet size for DSL leased line customers
On Tue, 1 Jan 2008 12:57:17 +0100 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 31 dec 2007, at 1:24, Mark Smith wrote: Another idea would be to give each non-/48 customer the first /56 out of each /48. Right, so you combine the downsides of both approaches. It doesn't work when ARIN does it: Well, ARIN aren't running the Internet route tables. If they were, I'd assume they'd force AS6453 to do the right thing and aggregate their address space. * 24.122.32.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.48.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.64.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.80.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.96.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.112.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.128.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.144.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.160.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.176.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.192.0/19 4.68.1.166 0 0 3356 6453 11290 i * 24.122.224.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.240.0/20 4.68.1.166 0 0 3356 6453 11290 i And it's unlikely to work here: for those standard size blocks, you really don't want any per-user config: you want those to be assigned automatically. But for the /48s you do need per-user config, if only that this user gets a /48. So these two block sizes can't realistically come from the same (sub-) range. Maybe I'm not understanding this correctly. Are you saying that customers who have a /56 would get dynamic ones i.e. a different one each time they reconnect? If they've got a routed downstream topology, with multiple routers and subnets (because of course, they've got 256 of them), I don't think customers will be very happy about having to renumber top /56 bits if e.g. they have a DSL line sync drop out and get a different /56. Static assignments of /56 to customers make sense to me, and that's the assumption I've made when suggesting the addressing scheme I proposed. Once you go static with /56s, you may as well make it easy for both yourself and the customer to move to a /48 that encompasses the original /56 (or configure the whole /48 for them from the outset). Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
On Mon, 31 Dec 2007 13:18:41 -0800 Joel Jaeggli [EMAIL PROTECTED] wrote: Mark Smith wrote: Another idea would be to give each non-/48 customer the first /56 out of each /48. If you started out with a /30 or /31 RIR block , by the time you run out of /48s, you can either start using up the subsequent /56s out of the first /48, as it's likely that the first /56 customer out of the /48 would have needed the /48 by that time. As stated, that approach has really negative implications for the number of routes you carry in your IGP. Well, for 120K+ customers, I doubt you're using an IGP for anything much more than BGP loopbacks - and you'd have to be aggregating routes at a higher layer in your routing hierarchy anyway, to cope with 120K routes, regardless of what method you use to dole out /48s or /56s to end-sites. Alternatively you might have become more comfortable with giving each customer a /48, and wouldn't require any of them to renumber - they'd just have to shorten their prefix length. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
On Tue, 1 Jan 2008 10:27:50 +1030 Mark Smith [EMAIL PROTECTED] wrote: On Mon, 31 Dec 2007 13:18:41 -0800 Joel Jaeggli [EMAIL PROTECTED] wrote: Mark Smith wrote: Another idea would be to give each non-/48 customer the first /56 out of each /48. If you started out with a /30 or /31 RIR block , by the time you run out of /48s, you can either start using up the subsequent /56s out of the first /48, as it's likely that the first /56 customer out of the /48 would have needed the /48 by that time. As stated, that approach has really negative implications for the number of routes you carry in your IGP. Well, for 120K+ customers, I doubt you're using an IGP for anything much more than BGP loopbacks - and you'd have to be aggregating routes at a higher layer in your routing hierarchy anyway, to cope with 120K routes, regardless of what method you use to dole out /48s or /56s to end-sites. It being New Year's Day and my brain not working right yet ... you'd probably divide your RIR block up across your PoPs, and then could use this technique within each PoP, with the PoP being the route aggregation boundary. Alternatively you might have become more comfortable with giving each customer a /48, and wouldn't require any of them to renumber - they'd just have to shorten their prefix length. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
Scott Weeks wrote: [..] I have about 100K DSL customers at this time and most all are households. 65K wouldn't cover that. At this point, I doubt that I'd require much more than just asking and making sure the person is understanding what they're asking for. Mostly, that'd be the leased line customers. Thus why didn't you request a larger prefix from ARIN then? Clearly you can justify it. Then again, if you are going to provide /56's to home users, nobody will think you are a bad person and most people will be quite happy already. In your case I would then reserve (probably topdown) /48's, for the larger sites/businesses and start allocating bottom-up for /56's to endusers. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: v6 subnet size for DSL leased line customers
--- [EMAIL PROTECTED] wrote: From: Jeroen Massar [EMAIL PROTECTED] Scott Weeks wrote: [..] I have about 100K DSL customers at this time and most all are households. 65K wouldn't cover that. At this point, I doubt that I'd require much more than just asking and making sure the person is understanding what they're asking for. Mostly, that'd be the leased line customers. Thus why didn't you request a larger prefix from ARIN then? Clearly you can justify it. Then again, if you are going to provide /56's to home users, nobody will think you are a bad person and most people will be quite happy already. In your case I would then reserve (probably topdown) /48's, for the larger sites/businesses and start allocating bottom-up for /56's to endusers. - I haven't requested anything yet. That's why I came to you folks. To learn and then get busy on it. Thanks for your top-down and bottom-up idea. I will probably also intersperse /56s in between allocations as well; filling them in later if it ever gets to that. scott
Re: v6 subnet size for DSL leased line customers
On Sun, 30 Dec 2007 12:08:34 +0100 Jeroen Massar [EMAIL PROTECTED] wrote: Scott Weeks wrote: [..] I have about 100K DSL customers at this time and most all are households. 65K wouldn't cover that. At this point, I doubt that I'd require much more than just asking and making sure the person is understanding what they're asking for. Mostly, that'd be the leased line customers. Thus why didn't you request a larger prefix from ARIN then? Clearly you can justify it. Then again, if you are going to provide /56's to home users, nobody will think you are a bad person and most people will be quite happy already. In your case I would then reserve (probably topdown) /48's, for the larger sites/businesses and start allocating bottom-up for /56's to endusers. Another idea would be to give each non-/48 customer the first /56 out of each /48. If you started out with a /30 or /31 RIR block , by the time you run out of /48s, you can either start using up the subsequent /56s out of the first /48, as it's likely that the first /56 customer out of the /48 would have needed the /48 by that time. Alternatively you might have become more comfortable with giving each customer a /48, and wouldn't require any of them to renumber - they'd just have to shorten their prefix length. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
Mark Smith [EMAIL PROTECTED] writes: On Thu, 27 Dec 2007 21:50:01 -0500 Robert E. Seastrom [EMAIL PROTECTED] wrote: I'd really, really, really like to have DHCP6 on the Mac. Autoconfig is not sufficient for this task unless there is some kind of trick you can do to make the eui-64 come out the same for both interfaces (don't think so). Don't know if Mac's can do bridging, but under Linux, all you'd need to do would be create bridge instance, assign the two or more interfaces to the bridge, and have DHCPv6 use the bridge virtual interface. The problem is that there is no DHCPv6 for the Mac (well, I suppose I could try building it by hand and see how far I get). I'm pretty sure that Macs aren't set up to do a layer 2 bridge group between their interfaces, and moreover I think this is risky behavior in terms of creating a loop if something goes wrong on the laptop even if the host OS supports it. ---rob
Re: v6 subnet size for DSL leased line customers
On Dec 27, 2007, at 11:19 PM, Mark Smith wrote: On Fri, 28 Dec 2007 12:57:45 +0900 Randy Bush [EMAIL PROTECTED] wrote: Ever calculated how many Ethernet nodes you can attach to a single LAN with 2^46 unicast addresses? you mean operationally successfully, or just for marketing glossies? Theoretically. What I find a bit hard to understand is peoples' seemingly complete acceptance of the 'gross' amount of ethernet address space there is available with 46 bits available for unicast addressing on a single LAN segment, yet confusion and struggle over the allocation of additional IPv6 bits addressing bits for the same purpose - the operational convenience of having addressing work out of the box or be simpler to understand and easier to work with. Once I realised that IPv6's fixed sized node addressing model was similar to Ethernet's, I then started wondering why Ethernet was like it was - and then found a paper that explains it : 48-bit Absolute Internet and Ethernet Host Numbers http://ethernethistory.typepad.com/papers/HostNumbers.pdf Would it be possible to find the even part of this paper ? This version only has the odd numbered pages. Regards Marshall Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
--- [EMAIL PROTECTED] wrote: From: Mark Smith [EMAIL PROTECTED] On Thu, 27 Dec 2007 18:08:10 -0800 Scott Weeks [EMAIL PROTECTED] wrote: I am thinking of a /56 for everyone and a /48 on request. Out of curiosity, what in form would a request for a /48 need to be? A checkbox on the application form, or some sort of written justification? Remember that with an initial RIR allocation of a /32, you've got 65K /48s ... so they're pretty cheap to give away. --- I have about 100K DSL customers at this time and most all are households. 65K wouldn't cover that. At this point, I doubt that I'd require much more than just asking and making sure the person is understanding what they're asking for. Mostly, that'd be the leased line customers. scott
Re: v6 subnet size for DSL leased line customers
On Sat, 29 Dec 2007 15:14:25 -0500 Marshall Eubanks [EMAIL PROTECTED] wrote: On Dec 27, 2007, at 11:19 PM, Mark Smith wrote: On Fri, 28 Dec 2007 12:57:45 +0900 Randy Bush [EMAIL PROTECTED] wrote: Ever calculated how many Ethernet nodes you can attach to a single LAN with 2^46 unicast addresses? you mean operationally successfully, or just for marketing glossies? Theoretically. What I find a bit hard to understand is peoples' seemingly complete acceptance of the 'gross' amount of ethernet address space there is available with 46 bits available for unicast addressing on a single LAN segment, yet confusion and struggle over the allocation of additional IPv6 bits addressing bits for the same purpose - the operational convenience of having addressing work out of the box or be simpler to understand and easier to work with. Once I realised that IPv6's fixed sized node addressing model was similar to Ethernet's, I then started wondering why Ethernet was like it was - and then found a paper that explains it : 48-bit Absolute Internet and Ethernet Host Numbers http://ethernethistory.typepad.com/papers/HostNumbers.pdf Would it be possible to find the even part of this paper ? This version only has the odd numbered pages. Hmm, you're right. The version I originally read was from somewhere else, and that was complete. I figured this one was more original as it's on one of the papers author's websites, so I've remembered that one, and even deleted my original electronic copy for this one. I'll try to find the other copy. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
On Sat, 29 Dec 2007 15:14:25 -0500 Marshall Eubanks [EMAIL PROTECTED] wrote: On Dec 27, 2007, at 11:19 PM, Mark Smith wrote: On Fri, 28 Dec 2007 12:57:45 +0900 Randy Bush [EMAIL PROTECTED] wrote: Would it be possible to find the even part of this paper ? This version only has the odd numbered pages. Here's where I got the version I first read. The full text/pdf is available if you have or create yourself an ACM login : http://portal.acm.org/citation.cfm?id=800081.802680 Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
Randy Bush wrote: vendors, like everyone else, will do what is in their best interests. as i am an operator, not a vendor, that is often not what is in my best interest, marketing literature aside. i believe it benefits the ops community to be honest when the two do not seem to coincide. If the ops community doesn't provide enough addresses and a way to use them then the vendors will do the same thing they did in v4. i presume you mean nat v6/v6. this would be a real mess and i don't think anyone is contending it is desirable. but this discussion is ostensibly operators trying to understand what is actually appropriate and useful for a class of customers, i believe those of the consumer, soho, and similar scale. to summarize the positions i think i have heard o one /64 subnet per device, but the proponent gave no estimate of the number of devices o /48 o /56 o /64 It plausible that if one were to assign a single /64 and reserve a 56 to delegate per customer that you could number about 16 million customers per /32 with a few hundred thousand /64s remaining for infrastrucuture. size of an agregate for a pop might be /48 (~250 customers) to /40 (65k customers) to /36 (1 million customers) A large retail isp might under those circumstances be able to get away with order of /28 to /30 in total. the latter three all assuming that the allocation would be different if the site had actual need and justification. personally, i do not see an end site needing more than 256 subnets *by default*, though i can certainly believe a small minority of them need more and would use the escape clause. so, if we, for the moment, stick to the one /64 per subnet religion, than a /56 seems sufficient for the default allocation. personally, i have a hard time thinking that any but a teensie minority, who can use the escape clause, need more than 256. hence, i just don't buy the /48 position.
Re: v6 subnet size for DSL leased line customers
It plausible that if one were to assign a single /64 and reserve a 56 to delegate per customer as a provider, where is the win in this for me? the space is 'lost', i.e. committed, and i increase provisioning hassles, though maybe mildly if i am skillful. if/when the rirs sober up about ipv6 justification, i will have a hard time showing an hd ratio without a lot of zeros to the immediate right of the decimal point. or would you suggest that i recover the committed space if unused? under what conditions? after how long? and, when i recover, do i allocate the second (or 42nd) /64 to a new customer, leaving them a smaller cushion than the first user of that /56 received? no easy answers. but yes, giving them a /56 off the bat feels a bit reminiscent of giving them a /24 in ipv4. randy
Re: v6 subnet size for DSL leased line customers
On Thu, 27 Dec 2007 21:50:01 -0500 Robert E. Seastrom [EMAIL PROTECTED] wrote: Leo Bicknell [EMAIL PROTECTED] writes: snip I'd really, really, really like to have DHCP6 on the Mac. Autoconfig is not sufficient for this task unless there is some kind of trick you can do to make the eui-64 come out the same for both interfaces (don't think so). Don't know if Mac's can do bridging, but under Linux, all you'd need to do would be create bridge instance, assign the two or more interfaces to the bridge, and have DHCPv6 use the bridge virtual interface. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
Personally, I'm not a big fan of DHCPv6. First of all, from a philosophical standpoint: I believe that stateless autoconfiguration is a better model in most cases (although it obviously doesn't support 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information. Which is probably going to make IPv6 deployment slower in service provider environments. There's also tons of ways to complicate your life by mixing stateless autoconf and DHCPv6, especially since most systems don't support DHCPv6 unless you install additional software. Last but not least, DHCPv6 has a stateful mode that's appropriate for address assignment or prefix delegation, and a stateless mode that's more efficient for the configuration of information that's not client-specific. Unfortunately, it's up to the client to initiate the desired mode. Then there are the M and O bits in RAs that tell you whether to do DHCPv6 but a number of DHCPv6 aficionados look like they want to ignore those bits. Again, this is something that's going to slow down deployment in service provider environments. Providers are comfortable with the IPv4 DHCP model (which is definitely not stateless) and many of us would like to keep this. What this all boils down to is that if you want to deploy DHCPv6 you need to install software on a lot of systems and modify a lot of configurations. If you're going to do all that, it's easier to simply configure this stuff manually. The only downside to that is that it's not compatible with easy renumbering, but then, you need to do more than just automate address assignment to support easy renumbering. Configure this stuff manually may work for a small number of customers. It is highly undesirable (and probably won't be considered at all) in an environment with, say, 1 million customers. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: v6 subnet size for DSL leased line customers
On 26 dec 2007, at 22:40, Leo Bicknell wrote: If you're a shop that uses such features today (MAC/Port tracking, DHCP snooping, etc) to secure your IPv4 infrastructure does IPv6 RA's represent a step backwards from a security perspective? Would IPv6 deployment be hindered until there is DHCPv6 snooping and DHCPv6 is able to provide a default gateway, a-la how it is done today in IPv4? It would be very interesting to me if the answer was it's moot because we're going to move to CGA's as a step forward; it would be equally interesting if the answer is CGA isn't ready for prime time / we can't deploy it for xyz reason, so IPv6 is less secure than IPv4 today and that's a problem. With IPv4, a lot of these features are developed by vendors and (sometimes) later standardized in the IETF or elsewhere. With IPv6, the vendors haven't quite caught up with the IETF standardization efforts yet, so the situation is samewhat different. For instance, SEND/CGA is excellent work, but we've only recently seen the first implementations. Personally, I'm not a big fan of DHCPv6. First of all, from a philosophical standpoint: I believe that stateless autoconfiguration is a better model in most cases (although it obviously doesn't support 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information. There's also tons of ways to complicate your life by mixing stateless autoconf and DHCPv6, especially since most systems don't support DHCPv6 unless you install additional software. Last but not least, DHCPv6 has a stateful mode that's appropriate for address assignment or prefix delegation, and a stateless mode that's more efficient for the configuration of information that's not client-specific. Unfortunately, it's up to the client to initiate the desired mode. Then there are the M and O bits in RAs that tell you whether to do DHCPv6 but a number of DHCPv6 aficionados look like they want to ignore those bits. What this all boils down to is that if you want to deploy DHCPv6 you need to install software on a lot of systems and modify a lot of configurations. If you're going to do all that, it's easier to simply configure this stuff manually. The only downside to that is that it's not compatible with easy renumbering, but then, you need to do more than just automate address assignment to support easy renumbering. I don't think IPv6 address configuration in general and DHCPv6 in particular will ever be fully equivalent to how things work with IPv4. This is really the place where the differences between the two protocols are the biggest. For those of us who are familiar with IPX, AppleTalk, CLNP and IPv4: IPv6 basically uses the address configuration methods from all of those, no wonder it can get a bit complex. That being said, please go to your vendors and tell them what you need. Preferably at a high level, so they can provide the functionality in the optimal way, rather than just revert back to the IPv4 way of doing things.
Re: v6 subnet size for DSL leased line customers
On 27 dec 2007, at 11:57, [EMAIL PROTECTED] wrote: Configure this stuff manually may work for a small number of customers. It is highly undesirable (and probably won't be considered at all) in an environment with, say, 1 million customers. Of course not. But RAs on a subnet with a million customers doesn't work either, nor does DHCP on a subnet with a million customers. If we're talking about provisioning cable/DSL/FTTH users, that's a completely different thing. Here, DHCPv6 prefix delegation to a CPE which then provides configuration to hosts on its LAN side would be the most appropriate option. However, the specifics of that model need to be worked out as there are currently no ISPs and no CPEs that do that, as far as I know.
Re: v6 subnet size for DSL leased line customers
Configure this stuff manually may work for a small number of customers. It is highly undesirable (and probably won't be considered at all) in an environment with, say, 1 million customers. Of course not. But RAs on a subnet with a million customers doesn't work either, nor does DHCP on a subnet with a million customers. It wouldn't be a subnet with a million customers, of course. We would typically have aggregation routers handling 5000 to 3 customers, each connected via (in our case) point to point DSL links. Important point here is that we *don't* want per-customer IPv4 (or IPv6) config on the aggregation routers - this is what we have DHCP servers for. If we're talking about provisioning cable/DSL/FTTH users, that's a completely different thing. Here, DHCPv6 prefix delegation to a CPE which then provides configuration to hosts on its LAN side would be the most appropriate option. However, the specifics of that model need to be worked out as there are currently no ISPs and no CPEs that do that, as far as I know. I agree that DHCPv6 prefix delegation (for instance a /56) to a CPE which provides configuration to hosts on its LAN side sounds like a reasonable model. It requires the customer to have a CPE with actual *router* functionality, as opposed to just a bridge. This is different from today's requirements, but may not be unreasonable. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: v6 subnet size for DSL leased line customers
On Thu, 27 Dec 2007 11:27:13 +0100 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 26 dec 2007, at 22:40, Leo Bicknell wrote: snip It would be very interesting to me if the answer was it's moot because we're going to move to CGA's as a step forward; it would be equally interesting if the answer is CGA isn't ready for prime time / we can't deploy it for xyz reason, so IPv6 is less secure than IPv4 today and that's a problem. With IPv4, a lot of these features are developed by vendors and (sometimes) later standardized in the IETF or elsewhere. With IPv6, the vendors haven't quite caught up with the IETF standardization efforts yet, so the situation is samewhat different. For instance, SEND/CGA is excellent work, but we've only recently seen the first implementations. Personally, I'm not a big fan of DHCPv6. First of all, from a philosophical standpoint: I believe that stateless autoconfiguration is a better model in most cases (although it obviously doesn't support 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. I think it's interesting CGAs are being discussed in the same email as the one where you say you want to be able to express prefix length in DHCPv6 - because I'm guessing you want that feature to be able to shorten node addresses. One of the benefits of fixed length node addresses, at the 64 bit boundary, is that it has made CGA much simpler - the CGA designers knew from the outset that they were dealing with a single, fixed length 64 bit field to store the results of their crypto functions. If people had different length autoconfigured or DHCPv6 learned addresses, not only would CGA have to had be designed to support those varying field lengths, increasing it's complexity (and therefore increasing opportunities for implementation related security failure aka bugs with security consequences), it's also likely that CGA would have had to incorporate parameter checks to prevent people enabling it, when the node address length they've chosen is too short for the security strength CGA is designed to provide. If you don't perform these sorts of checks, then too weak CGA, because of too short node addresses, might give people a false sense of security - and I think that's far worse than no security at all. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
On Thu, 27 Dec 2007 12:11:54 +0100 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 27 dec 2007, at 11:57, [EMAIL PROTECTED] wrote: Configure this stuff manually may work for a small number of customers. It is highly undesirable (and probably won't be considered at all) in an environment with, say, 1 million customers. Of course not. But RAs on a subnet with a million customers doesn't work either, nor does DHCP on a subnet with a million customers. If we're talking about provisioning cable/DSL/FTTH users, that's a completely different thing. Here, DHCPv6 prefix delegation to a CPE which then provides configuration to hosts on its LAN side would be the most appropriate option. However, the specifics of that model need to be worked out as there are currently no ISPs and no CPEs that do that, as far as I know. I haven't had a chance to test it, but according to Deploying IPv6 Networks, IOS can support DHCPv6 based prefix delegation. It even supports multiple downstream interfaces on the CPE - you configure the subnet number you want on each of the interfaces, and the CPE will configure the DHCP-PD learned /48 on the front of them automatically and then start announcing those prefixes in RAs out those interfaces. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
In a message written on Thu, Dec 27, 2007 at 11:27:13AM +0100, Iljitsch van Beijnum wrote: 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information. I would note, it's not too late to fix these problems. We don't have wide spread IPv6 deployment yet, and I can't imagine it's all that hard to send a default gateway in DHCPv6, for example. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpgZ7FayQI7H.pgp Description: PGP signature
Re: v6 subnet size for DSL leased line customers
On Dec 27, 2007 5:27 AM, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: With IPv4, a lot of these features are developed by vendors and (sometimes) later standardized in the IETF or elsewhere. With IPv6, the vendors haven't quite caught up with the IETF standardization efforts yet, so the situation is samewhat different. For instance, SEND/CGA is excellent work, but we've only recently seen the first implementations. first implementations, in a protocol that's 'fully baked' (according to ietf closing down the v6 WG) and been in 'production' for 15 years? for features that have existed in the v4 network for 5+ years? ouch... This gets back to my point about having feature parity and the fact that that is important. People have deployed rather large environments that require these features, not having them is a step backwards and painful for the operators in question. What this all boils down to is that if you want to deploy DHCPv6 you need to install software on a lot of systems and modify a lot of 'the largest deployed platform' already has this built-in, yes? (vista/xp) configurations. If you're going to do all that, it's easier to simply configure this stuff manually. The only downside to that is that it's you are crazy... seriously, have you walked around to 10k or 50k machines or attempted to get helpdesky people to do the same? have you considered that this all works fine in v4, is tied into my OSS backends and is a part of my business process? Getting some new software (firefox is a fine example) deployed to 50k workstations is an overnight event... SMS (or whatever the new MS equivalent is) rolls out the software update, there are many other options (tivoli, ca-unicenter, custom-foo) which will also do this work for you, getting proper and dynamic setup of IP info (my earlier example of resolvers) isn't quite as simple unless you use dhcp. not compatible with easy renumbering, but then, you need to do more than just automate address assignment to support easy renumbering. sure, like deploy v6... wait, that doesn't do it either :( It's not just renumbering, it's migration of services which the network elements are reliant on (dns, wins, tftp-root/nfs-root...) tieing my laptop to the same addr each time for some process including logs and HR details and SoX compliance perhaps. This is a bighairy beast, just saying 'dhcpv6 isnt possible use autoconf' is never going to be acceptable. That being said, please go to your vendors and tell them what you need. Preferably at a high level, so they can provide the functionality in the optimal way, rather than just revert back to the IPv4 way of doing things. also be sure to let your standards body(s) know that some form of feature parity is relevant. I think often there is a missing message between operators and the other folks :( this clearly (to me atleast) seems like one of those areas. -Chris
Re: v6 subnet size for DSL leased line customers
On 27 dec 2007, at 12:44, [EMAIL PROTECTED] wrote: I agree that DHCPv6 prefix delegation (for instance a /56) to a CPE which provides configuration to hosts on its LAN side sounds like a reasonable model. It requires the customer to have a CPE with actual *router* functionality, as opposed to just a bridge. This is different from today's requirements, but may not be unreasonable. Ok, that would be CPE == modem. Another line of thought would be a bridging modem + a routing CPE that the customer provides. This would be similar to the home routers that you can buy today. (A lot of ISPs, especially in the are I just moved to, insist on providing you with a free router rather than just a modem, yuck!) Ideally, a bridging modem would be able to talk to both individual hosts, just like it can on IPv4, or to a router provided by the customer. But unlike with IPv4, these modes of operation would have to be different in the absense of NAT. Providing a prefix to a user is actually the simple part, because there is really only one way to do it (short of manual configuration): DHCPv6 prefix delegation. The trouble is how ISP equipment talks to the first IPv6 device on the customer side. The easy way would be to have a separate VLAN and IPv6 subnet for that for each customer but I gather that means more expensive equipment. Using the IPv4 model with DHCPv6 wouldn't work well because of the low DHCPv6 adoption. (This problem may or may not go away in time; I gather that Vista has it but that Apple isn't interested in adopting DHCPv6.) However, rather than snooping DHCP messages and inserting DHCP options, with IPv6 DSL/cable equipment on the ISP side (or even the modem) could intercept and modify router advertisements so each customer gets their own prefix advertised. If we then do some ingress filtering based on that prefix and force all traffic through the first IPv6 router on the ISP side this could work very well. Interestingly, in IPv6 there is no need for a default gateway to have an address in the subnet prefix that hosts use. So the problem that you'd have with this in IPv4, that two neighbors can't communicate because the hosts think they're on the same IP subnet but direct traffic between them is blocked, doesn't occur. (Unless the router sends redirects.) On 27 dec 2007, at 13:11, Mark Smith wrote: I think it's interesting CGAs are being discussed in the same email as the one where you say you want to be able to express prefix length in DHCPv6 - because I'm guessing you want that feature to be able to shorten node addresses. Actually I spoke up against that in the last IETF meeting. Maybe in 20 years when we made such a mess of the other bits that we need to recover some of those interface identifier bits. The issue with lacking a prefix length in DHCPv6 doesn't really lead to any trouble in normal operation, but it does make DHCPv6 mostly useless in one of the cases that it's advertised for: the situation where there is no router on the subnet. In that case, if host A gets 2001::a and host B gets 2001::b but they don't know the subnet size, the conservative assumption is /128 which means that they can't communicate. Hardcoding /64 would be bad, even in router advertisements the prefix length is carried explicitly even though stateless autoconfig won't work if it's not 64. On 27 dec 2007, at 13:19, Mark Smith wrote: there are currently no ISPs and no CPEs that do that, as far as I know. I haven't had a chance to test it, but according to Deploying IPv6 Networks, IOS can support DHCPv6 based prefix delegation. It even supports multiple downstream interfaces on the CPE - you configure the subnet number you want on each of the interfaces, and the CPE will configure the DHCP-PD learned /48 on the front of them automatically and then start announcing those prefixes in RAs out those interfaces. You're absolutely right. For some reason it never connected in my brain that my Cisco 826/827 (I always forget which) ADSL router supports this, even with a 3 year old IOS. I think when I tested this I did so on a bunch of 2500s. But if you look at Apple's Airport Extreme base station, for instance, that box will only terminate a tunnel and not handle any kind of native IPv6 routing. See http://www1.ietf.org/mail-archive/web/ipv6/current/msg08798.html for a small config example. (I think someone said the Airport Extreme bridges IPv6 and routes IPv4 (or maybe the other way around), which isn't true. You can configure it to bridge or do IPv4 NAT and separately from that to route between an IPv6 manual or 6to4 tunnel and the LAN ports (+ WAN port when bridging).)
Re: v6 subnet size for DSL leased line customers
On 27 dec 2007, at 20:26, Christopher Morrow wrote: With IPv4, a lot of these features are developed by vendors and (sometimes) later standardized in the IETF or elsewhere. With IPv6, the vendors haven't quite caught up with the IETF standardization efforts yet, so the situation is samewhat different. For instance, SEND/CGA is excellent work, but we've only recently seen the first implementations. first implementations, in a protocol that's 'fully baked' (according to ietf closing down the v6 WG) and been in 'production' for 15 years? You suggest that I said that IPv6 has only recently seen the first implementations. I was talking about CGA/SEND, not IPv6 proper, which was standardized some 12 years ago. for features that have existed in the v4 network for 5+ years? ouch... This gets back to my point about having feature parity Some of the features of IPv4 are actually glaring holes that some people have found a use for. Also, SEND is something that doesn't exist in IPv4 so your complaint doesn't apply here. and the fact that that is important. People have deployed rather large environments that require these features, not having them is a step backwards and painful for the operators in question. Please direct your feature request to your favorite vendors... What this all boils down to is that if you want to deploy DHCPv6 you need to install software on a lot of systems and modify a lot of 'the largest deployed platform' already has this built-in, yes? (vista/xp) Vista: yes, it seems. XP, no so much. Windows XP can't even do DNS lookups over IPv6, which basically means that you can't use an XP machine on an IPv6-only network. If you're going to do all that, it's easier to simply configure this stuff manually. The only downside to that is that it's you are crazy... seriously, have you walked around to 10k or 50k machines or attempted to get helpdesky people to do the same? have you considered that this all works fine in v4, is tied into my OSS backends and is a part of my business process? Getting some new software (firefox is a fine example) deployed to 50k workstations is an overnight event... SMS (or whatever the new MS equivalent is) rolls out the software update, there are many other options (tivoli, ca-unicenter, custom-foo) which will also do this work for you, getting proper and dynamic setup of IP info (my earlier example of resolvers) isn't quite as simple unless you use dhcp. It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. just saying 'dhcpv6 isnt possible use autoconf' is never going to be acceptable. Never said it isn't possible. But unlike with IPv4, where DHCP is the default answer unless you're really sure you need manual configuration, DHCPv6 isn't the default answer for IPv6. That being said, please go to your vendors and tell them what you need. Preferably at a high level, so they can provide the functionality in the optimal way, rather than just revert back to the IPv4 way of doing things. also be sure to let your standards body(s) know that some form of feature parity is relevant. I think often there is a missing message between operators and the other folks :( this clearly (to me atleast) seems like one of those areas. Taken to its extreme feature parity means a search and replace of all IPv4 specs to make every instance of 32 bits 128 bits but not changing anything else. That's not what IPv6 is.
Re: v6 subnet size for DSL leased line customers
On Thu, 27 Dec 2007 22:57:59 +0100 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 27 dec 2007, at 20:26, Christopher Morrow wrote: snip Taken to its extreme feature parity means a search and replace of all IPv4 specs to make every instance of 32 bits 128 bits but not changing anything else. That's not what IPv6 is. Exactly. IPv6 is similar enough to IPv4 that it makes it easier to learn than if it were a completely new and unrelated protocol. It's different enough that you need to take each of the concepts and practices that you know and have used for IPv4 for many years and try to objectively evaluate whether they're still valid for IPv6. IPv6 has features that IPv4 has never had, but have existed in IPX and Appletalk since they were designed many years ago. If people have the time, learning about those protocols might help with more easily learning about IPv6. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpy9pOPQJ1De.pgp Description: PGP signature
Re: v6 subnet size for DSL leased line customers
First, thanks everyone for the discussion. I learned more from this than a LOT of other discussions on IPv6. I now have a plan and I didn't before... It looks to me that one really has to know his customer's needs to plan out the allocation of IPv6 space. That leads me to believe that a /56 is going to work for everyone on this network because, at this time, only very, very few of our largest customers might possibly have a need for more than 256 /64 subnets. In fact, almost all household DSL customers here only have one LAN and I could get away with /64s for them because they wouldn't know the difference. But in an effort to simplify the lives of the network folks here I am thinking of a /56 for everyone and a /48 on request. Now I just gotta wrap my brain around 4.7x10^21 addresses for each customer. Absolutely staggering. scott --- [EMAIL PROTECTED] wrote: From: Randy Bush [EMAIL PROTECTED] To: Joel Jaeggli [EMAIL PROTECTED] CC: nanog@merit.edu Subject: Re: v6 subnet size for DSL leased line customers Date: Thu, 27 Dec 2007 13:19:27 +0900 vendors, like everyone else, will do what is in their best interests. as i am an operator, not a vendor, that is often not what is in my best interest, marketing literature aside. i believe it benefits the ops community to be honest when the two do not seem to coincide. If the ops community doesn't provide enough addresses and a way to use them then the vendors will do the same thing they did in v4. i presume you mean nat v6/v6. this would be a real mess and i don't think anyone is contending it is desirable. but this discussion is ostensibly operators trying to understand what is actually appropriate and useful for a class of customers, i believe those of the consumer, soho, and similar scale. to summarize the positions i think i have heard o one /64 subnet per device, but the proponent gave no estimate of the number of devices o /48 o /56 o /64 the latter three all assuming that the allocation would be different if the site had actual need and justification. personally, i do not see an end site needing more than 256 subnets *by default*, though i can certainly believe a small minority of them need more and would use the escape clause. so, if we, for the moment, stick to the one /64 per subnet religion, than a /56 seems sufficient for the default allocation. personally, i have a hard time thinking that any but a teensie minority, who can use the escape clause, need more than 256. hence, i just don't buy the /48 position. personally, i agree that one subnet is likely to be insufficient in a large proportion of cases. so keeping to the /64 per subnet religion, a /64 per site is insufficient for the default. still personally, i think the one /64 subnet per device is analogous to one receptacle per mains breaker, i.e. not sensible. there are three legs to the tripod network operator user equipment manufacturer They have (or should have) a mutual interest in: Transparent and automatic configuration of devices. as you have seen from chris's excellent post [0] on this one, one size does not fit all. this is likely another worthwhile, but separate, discussion. The assignment of globally routable addresses to internet connected devices i suspect that there are folk out there who equate nat with security. i suspect we both think them misguided. The user having some control over what crosses the boundry between their network and the operators. yup randy --- [0] - http://www.merit.edu/mail.archives/nanog/msg04887.html
[DCHPv6] was Re: v6 subnet size for DSL leased line customers
And, besides the list forwarded below, Designated printers, Preferred DNS Servers, and, maybe, more. Even in a large enterprise, the ratio of routers to DHCP servers makes control of many end system parameters via DHCP a management win compared to configuration of routers with this non-network core data. (In case I was to abstruse, It is cheaper to maintain end system parameters in a smaller number of DHCP servers than in a larger number of routers.) This is completely separate from the fact that many experienced router engineers are smart enough configure routers with NTP server addresses in preference to DNS names, and likewise for many other parameters. The end system population has requirements which respond much more dynamically to business requirements than do router configurations, which respond mostly to wiring configurations which are, by comparison, static. The statement that DHCP is not needed for IPv6 packet routing may well be exactly accurate. The absence of good DHCP support in IPv6 has costly consequences for enterprise management, of which IP routing is a small part. You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box! Cutler Begin forwarded message: From: Leo Bicknell [EMAIL PROTECTED] Date: December 27, 2007 7:33:08 PM EST To: North American Network Operators Group nanog@merit.edu Subject: Re: v6 subnet size for DSL leased line customers In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org James R. Cutler [EMAIL PROTECTED]
Re: v6 subnet size for DSL leased line customers
Leo Bicknell [EMAIL PROTECTED] writes: In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. I'm running (native) IPv6 at home, and in the colo too. Most of my ssh sessions to personally owned machines go over v6. My laptops (with a single exception) are Macs. You may not be aware that the Mac is fairly smart about which interface it uses for connections - it will prefer the gigabit ethernet to the wireless when it sees link... it prefers wireless to dialup too. Basically, whenever you establish a new outgoing session it will use the lowest cost interface to do the deed. For IPv4, I have the same address manually assigned on the DHCP server to both the gigabit ethernet's MAC address and the wireless interface's MAC address. This means that when I plug into the gige, as I do for filesharing or backing some files up, the Mac uses the gigabit ethernet. When I unplug and carry the Mac to the conference room, *all existing upper layer sessions are preserved* - TCP and friends are blissfully unaware that a change has taken place; one gratuitous arp so the router knows where to send the packets and we're on our way again with nary a hiccup. I don't have an ssh session croak just because I connected or disconnected a cable. I'd really, really, really like to have DHCP6 on the Mac. Autoconfig is not sufficient for this task unless there is some kind of trick you can do to make the eui-64 come out the same for both interfaces (don't think so). Anyone from Apple reading this list? :-) ---Rob
Re: v6 subnet size for DSL leased line customers
On Dec 27, 2007, at 9:50 PM, Robert E. Seastrom wrote: Leo Bicknell [EMAIL PROTECTED] writes: In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. I'm running (native) IPv6 at home, and in the colo too. Most of my ssh sessions to personally owned machines go over v6. My laptops (with a single exception) are Macs. You may not be aware that the Mac is fairly smart about which interface it uses for connections - it will prefer the gigabit ethernet to the wireless when it sees link... it prefers wireless to dialup too. Basically, whenever you establish a new outgoing session it will use the lowest cost interface to do the deed. For IPv4, I have the same address manually assigned on the DHCP server to both the gigabit ethernet's MAC address and the wireless interface's MAC address. This means that when I plug into the gige, as I do for filesharing or backing some files up, the Mac uses the gigabit ethernet. When I unplug and carry the Mac to the conference room, *all existing upper layer sessions are preserved* - TCP and friends are blissfully unaware that a change has taken place; one gratuitous arp so the router knows where to send the packets and we're on our way again with nary a hiccup. I don't have an ssh session croak just because I connected or disconnected a cable. I'd really, really, really like to have DHCP6 on the Mac. Autoconfig is not sufficient for this task unless there is some kind of trick you can do to make the eui-64 come out the same for both interfaces (don't think so). Anyone from Apple reading this list? :-) Don't know, but I bet they read the MacnetworkProg list - they are present on all the Apple hosted lists I am on. See http://lists.apple.com/mailman/listinfo/macnetworkprog from http://lists.apple.com/mailman/listinfo Regards Marshall ---Rob
Re: [DCHPv6] was Re: v6 subnet size for DSL leased line customers
I have a modest proposal for providing the functionality of DHCPv4 in IPv6 autoconf: How about using the mechanism in RFC 5075 to specify all of these variables as RA flags? And as long as the variables also get defined as DHCPv6 fields, perhaps we could plan on having prefix delegation include these options, which the requesting router could then turn around and include in the RAs sent out on the link toward the customer. Am I missing something? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com --- On Thu, 12/27/07, James R. Cutler [EMAIL PROTECTED] wrote: From: James R. Cutler [EMAIL PROTECTED] Subject: [DCHPv6] was Re: v6 subnet size for DSL leased line customers To: North American Network Operators Group nanog@merit.edu Date: Thursday, December 27, 2007, 9:37 PM And, besides the list forwarded below, Designated printers, Preferred DNS Servers, and, maybe, more. Even in a large enterprise, the ratio of routers to DHCP servers makes control of many end system parameters via DHCP a management win compared to configuration of routers with this non-network core data. (In case I was to abstruse, It is cheaper to maintain end system parameters in a smaller number of DHCP servers than in a larger number of routers.) This is completely separate from the fact that many experienced router engineers are smart enough configure routers with NTP server addresses in preference to DNS names, and likewise for many other parameters. The end system population has requirements which respond much more dynamically to business requirements than do router configurations, which respond mostly to wiring configurations which are, by comparison, static. The statement that DHCP is not needed for IPv6 packet routing may well be exactly accurate. The absence of good DHCP support in IPv6 has costly consequences for enterprise management, of which IP routing is a small part. You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box! Cutler Begin forwarded message: From: Leo Bicknell [EMAIL PROTECTED] Date: December 27, 2007 7:33:08 PM EST To: North American Network Operators Group nanog@merit.edu Subject: Re: v6 subnet size for DSL leased line customers In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org James R. Cutler [EMAIL PROTECTED] Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Re: v6 subnet size for DSL leased line customers
On Thu, 27 Dec 2007 18:08:10 -0800 Scott Weeks [EMAIL PROTECTED] wrote: First, thanks everyone for the discussion. I learned more from this than a LOT of other discussions on IPv6. I now have a plan and I didn't before... It looks to me that one really has to know his customer's needs to plan out the allocation of IPv6 space. That leads me to believe that a /56 is going to work for everyone on this network because, at this time, only very, very few of our largest customers might possibly have a need for more than 256 /64 subnets. In fact, almost all household DSL customers here only have one LAN and I could get away with /64s for them because they wouldn't know the difference. But in an effort to simplify the lives of the network folks here I am thinking of a /56 for everyone and a /48 on request. Out of curiosity, what in form would a request for a /48 need to be? A checkbox on the application form, or some sort of written justification? Remember that with an initial RIR allocation of a /32, you've got 65K /48s ... so they're pretty cheap to give away. Now I just gotta wrap my brain around 4.7x10^21 addresses for each customer. Absolutely staggering. Ever calculated how many Ethernet nodes you can attach to a single LAN with 2^46 unicast addresses? That's a staggering number too. Regards, Mark. scott --- [EMAIL PROTECTED] wrote: From: Randy Bush [EMAIL PROTECTED] To: Joel Jaeggli [EMAIL PROTECTED] CC: nanog@merit.edu Subject: Re: v6 subnet size for DSL leased line customers Date: Thu, 27 Dec 2007 13:19:27 +0900 vendors, like everyone else, will do what is in their best interests. as i am an operator, not a vendor, that is often not what is in my best interest, marketing literature aside. i believe it benefits the ops community to be honest when the two do not seem to coincide. If the ops community doesn't provide enough addresses and a way to use them then the vendors will do the same thing they did in v4. i presume you mean nat v6/v6. this would be a real mess and i don't think anyone is contending it is desirable. but this discussion is ostensibly operators trying to understand what is actually appropriate and useful for a class of customers, i believe those of the consumer, soho, and similar scale. to summarize the positions i think i have heard o one /64 subnet per device, but the proponent gave no estimate of the number of devices o /48 o /56 o /64 the latter three all assuming that the allocation would be different if the site had actual need and justification. personally, i do not see an end site needing more than 256 subnets *by default*, though i can certainly believe a small minority of them need more and would use the escape clause. so, if we, for the moment, stick to the one /64 per subnet religion, than a /56 seems sufficient for the default allocation. personally, i have a hard time thinking that any but a teensie minority, who can use the escape clause, need more than 256. hence, i just don't buy the /48 position. personally, i agree that one subnet is likely to be insufficient in a large proportion of cases. so keeping to the /64 per subnet religion, a /64 per site is insufficient for the default. still personally, i think the one /64 subnet per device is analogous to one receptacle per mains breaker, i.e. not sensible. there are three legs to the tripod network operator user equipment manufacturer They have (or should have) a mutual interest in: Transparent and automatic configuration of devices. as you have seen from chris's excellent post [0] on this one, one size does not fit all. this is likely another worthwhile, but separate, discussion. The assignment of globally routable addresses to internet connected devices i suspect that there are folk out there who equate nat with security. i suspect we both think them misguided. The user having some control over what crosses the boundry between their network and the operators. yup randy --- [0] - http://www.merit.edu/mail.archives/nanog/msg04887.html -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
Ever calculated how many Ethernet nodes you can attach to a single LAN with 2^46 unicast addresses? you mean operationally successfully, or just for marketing glossies? randy
Re: v6 subnet size for DSL leased line customers
On Fri, 28 Dec 2007 12:57:45 +0900 Randy Bush [EMAIL PROTECTED] wrote: Ever calculated how many Ethernet nodes you can attach to a single LAN with 2^46 unicast addresses? you mean operationally successfully, or just for marketing glossies? Theoretically. What I find a bit hard to understand is peoples' seemingly complete acceptance of the 'gross' amount of ethernet address space there is available with 46 bits available for unicast addressing on a single LAN segment, yet confusion and struggle over the allocation of additional IPv6 bits addressing bits for the same purpose - the operational convenience of having addressing work out of the box or be simpler to understand and easier to work with. Once I realised that IPv6's fixed sized node addressing model was similar to Ethernet's, I then started wondering why Ethernet was like it was - and then found a paper that explains it : 48-bit Absolute Internet and Ethernet Host Numbers http://ethernethistory.typepad.com/papers/HostNumbers.pdf Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
On Fri, Dec 28, 2007, Mark Smith wrote: Once I realised that IPv6's fixed sized node addressing model was similar to Ethernet's, I then started wondering why Ethernet was like it was - and then found a paper that explains it : 48-bit Absolute Internet and Ethernet Host Numbers http://ethernethistory.typepad.com/papers/HostNumbers.pdf Question. Whats the ethernet 48-bit MAC space usage atm? Does anyone have a graph showing an E-Day? :) Adrian
Re: v6 subnet size for DSL leased line customers
On Fri, 28 Dec 2007 13:36:56 +0900 Adrian Chadd [EMAIL PROTECTED] wrote: On Fri, Dec 28, 2007, Mark Smith wrote: Once I realised that IPv6's fixed sized node addressing model was similar to Ethernet's, I then started wondering why Ethernet was like it was - and then found a paper that explains it : 48-bit Absolute Internet and Ethernet Host Numbers http://ethernethistory.typepad.com/papers/HostNumbers.pdf Question. Whats the ethernet 48-bit MAC space usage atm? Does anyone have a graph showing an E-Day? :) Apparently there's a foreseeable one, hence EUI-64s. Novell'll have to extend their IPX node addressing to 64 bits. Regards, Mark. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
If the ops community doesn't provide enough addresses and a way to use them then the vendors will do the same thing they did in v4. It's not clear to me where their needs don't coincide in this case. there are three legs to the tripod network operator user equipment manufacturer They have (or should have) a mutual interest in: Transparent and automatic configuration of devices. The assignment of globally routable addresses to internet connected devices the user having some control over what crosses the boundry between their network and the operators. Yes, well, that sounds fine, but I think that we've already hashed over at least some of the pressures on businesses in this thread. I've tried to focus on what's in the Subject:, and have mostly ignored other problems, which would include things such as cellular service, where I suspect that the service model is such that they'll want to find a way to allocate users a /128 ... There is, further, an effect which leads to equipment mfr being split into netwk equipment mfr and cpe equipment mfr, because the CPE guys will be trying to build things that'll work for the end user, working around any brokenness, etc. The problem space is essentially polarized, between network operators who have their own interests, and users who have theirs. So, as /engineers/ for the network operators, the question is, what can we do to encourage/coerce/force the businesses on our side of the equation to allocate larger rather than smaller numbers of bits, or find other solutions? What could we do to encourage, or better yet, mandate, that an ISP end- user connection should be allocated a minimum of /56, even if it happens to be a cellular service? ( :-) ) What do we do about corporate environments, or any other environment where there may be pressure to control topology to avoid DHCP PD to devices added to the network on an ad-hoc basis? Is it actually an absolutely unquestionable state of affairs that the smallest autoconfigurable subnet is a /64? Because if not, there are options there ... but of course, that leads down a road where an ISP may not want to allocate as much as a /64 ... What parts of this can we tackle through RIR policy? RFC requirements? Best practice? Customer education? ( :-) ) Other ideas? ... 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
In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500, Kevin Loch wrote: 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 I would like to point out that in IPv4 we have ICMP Router Advertisement messages. I have never seen them used on a production network. I know one of the worries is security, that a compromised host could send out advertisements, drawing traffic to it that it can then snoop and pass on to the real gateway. Having not looked in great detail, I am unclear if IPv6 has done something to fix this concern or not. Is this feature going to get turned off when the first worm comes along that spoofs RA's -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpkunR03iHNX.pgp Description: PGP signature
Re: v6 subnet size for DSL leased line customers
* Leo Bicknell: In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500, Kevin Loch wrote: 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 I would like to point out that in IPv4 we have ICMP Router Advertisement messages. I have never seen them used on a production network. I know one of the worries is security, that a compromised host could send out advertisements, drawing traffic to it that it can then snoop and pass on to the real gateway. DHCP and ARP face the same issue. That's why one host per subnet is so appealing.
Re: v6 subnet size for DSL leased line customers
* Tim Durack: Probably why some vendors support dhcp snooping and private vlans for IPv4 - multiple clients per subnet with isolation. The isolation is far from perfect because you don't know from which host the packet actually came. 8-(
Re: v6 subnet size for DSL leased line customers
On Dec 26, 2007, at 8:26 AM, Leo Bicknell wrote: In a message written on Tue, Dec 25, 2007 at 12:43:45AM -0500, Kevin Loch wrote: 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 I would like to point out that in IPv4 we have ICMP Router Advertisement messages. I have never seen them used on a production network. I know one of the worries is security, that a compromised host could send out advertisements, drawing traffic to it that it can then snoop and pass on to the real gateway. Having not looked in great detail, I am unclear if IPv6 has done something to fix this concern or not. Is this feature going to get turned off when the first worm comes along that spoofs RA's It's unlikely that it will matter. In practice, ICMP router discovery died a long time ago, thanks to neglect. Host vendors didn't adopt it, and it languished. The problem eventually got solved with HSRP and its clone, VRRP. This doesn't resolve the real underlying problem: Ethernet is inherently insecure. MAC addresses can be forged, protocols (ARP, ND) can be forged and at this point, there's not much that we can do about it. Architecturally, we need authentication over each and every control plane packet sent. Getting there without invoking the full complexity of a public key infrastructure is still an unsolved problem, AFAIK. Tony
Re: v6 subnet size for DSL leased line customers
On 26 dec 2007, at 19:22, Tony Li wrote: This doesn't resolve the real underlying problem: Ethernet is inherently insecure. MAC addresses can be forged, protocols (ARP, ND) can be forged and at this point, there's not much that we can do about it. Architecturally, we need authentication over each and every control plane packet sent. Getting there without invoking the full complexity of a public key infrastructure is still an unsolved problem, AFAIK. Actually, for this particular purpose, this is mostly a solved problem, although there is of course no free lunch. Many switches can enforce a MAC/port relationship, so that MAC addresses can't be spoofed. Neighbor discovery and router advertisements can be secured with SEND (SEcure Neighbor Discovery). This happens through CGAs, cryptograpically generated addresses. Basically, the lower 64 bits of the IPv6 address contains a hash over a public key. This makes it possible to prove ownership over an address. The not free part is that you need to configure certificates for trust relationships = the routers that may be default gateways.
Re: v6 subnet size for DSL leased line customers
Tony Li wrote: On Dec 26, 2007, at 8:26 AM, Leo Bicknell wrote: It's unlikely that it will matter. In practice, ICMP router discovery died a long time ago, thanks to neglect. Host vendors didn't adopt it, and it languished. The problem eventually got solved with HSRP and its clone, VRRP. Its been available from microsoft since windows2000, and according to documentation, on by default. I am not quite sure this can be blamed on vendors as opposed to users. http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/33574.mspx?mfr=true
Re: v6 subnet size for DSL leased line customers
In a message written on Wed, Dec 26, 2007 at 09:19:54PM +0100, Iljitsch van Beijnum wrote: Many switches can enforce a MAC/port relationship, so that MAC addresses can't be spoofed. Which gets to the crux of my question. If you're a shop that uses such features today (MAC/Port tracking, DHCP snooping, etc) to secure your IPv4 infrastructure does IPv6 RA's represent a step backwards from a security perspective? Would IPv6 deployment be hindered until there is DHCPv6 snooping and DHCPv6 is able to provide a default gateway, a-la how it is done today in IPv4? It would be very interesting to me if the answer was it's moot because we're going to move to CGA's as a step forward; it would be equally interesting if the answer is CGA isn't ready for prime time / we can't deploy it for xyz reason, so IPv6 is less secure than IPv4 today and that's a problem. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpFRvP23uRdF.pgp Description: PGP signature
Re: v6 subnet size for DSL leased line customers
vendors, like everyone else, will do what is in their best interests. as i am an operator, not a vendor, that is often not what is in my best interest, marketing literature aside. i believe it benefits the ops community to be honest when the two do not seem to coincide. If the ops community doesn't provide enough addresses and a way to use them then the vendors will do the same thing they did in v4. i presume you mean nat v6/v6. this would be a real mess and i don't think anyone is contending it is desirable. but this discussion is ostensibly operators trying to understand what is actually appropriate and useful for a class of customers, i believe those of the consumer, soho, and similar scale. to summarize the positions i think i have heard o one /64 subnet per device, but the proponent gave no estimate of the number of devices o /48 o /56 o /64 the latter three all assuming that the allocation would be different if the site had actual need and justification. personally, i do not see an end site needing more than 256 subnets *by default*, though i can certainly believe a small minority of them need more and would use the escape clause. so, if we, for the moment, stick to the one /64 per subnet religion, than a /56 seems sufficient for the default allocation. personally, i have a hard time thinking that any but a teensie minority, who can use the escape clause, need more than 256. hence, i just don't buy the /48 position. personally, i agree that one subnet is likely to be insufficient in a large proportion of cases. so keeping to the /64 per subnet religion, a /64 per site is insufficient for the default. still personally, i think the one /64 subnet per device is analogous to one receptacle per mains breaker, i.e. not sensible. there are three legs to the tripod network operator user equipment manufacturer They have (or should have) a mutual interest in: Transparent and automatic configuration of devices. as you have seen from chris's excellent post [0] on this one, one size does not fit all. this is likely another worthwhile, but separate, discussion. The assignment of globally routable addresses to internet connected devices i suspect that there are folk out there who equate nat with security. i suspect we both think them misguided. The user having some control over what crosses the boundry between their network and the operators. yup randy --- [0] - http://www.merit.edu/mail.archives/nanog/msg04887.html
Re: v6 subnet size for DSL leased line customers
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. For those of us with lots of IPv4 customers dependent on DHCP, it would be good to know more detail about this point. What is the problem, and are there plans to do anything about it in DHCPv6? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: v6 subnet size for DSL leased line customers
On Mon, 24 Dec 2007, Jeroen Massar wrote: 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 (* = 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) I don't have an MBA either. However I will note that many european airlines itemise their bills such that external costs (like taxes, shared-resource fees, etc) are seperated out. This practice seems particularly popular with low-cost airlines, as it allows them to advertise rock-bottom fares, where that fare is just the cost they have control of. So there seems to be real-world precedent for your proposal, in one of the tightest-margin and most cost-sensitive industries around. Prettige kerstdagen! regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: If you look good and dress well, you don't need a purpose in life. -- Robert Pante, fashion consultant
Re: v6 subnet size for DSL leased line customers
On 25 dec 2007, at 6:43, Kevin Loch wrote: 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? In my opinion, having hosts with different default gateways on the same LAN is not the most desirable way to build a network. If you have hosts with multiple interfaces and you want to set routes on those host for stuff that's reachable through a router on the interface that's not talking to the default router, then I agree VRRP would be useful. But again, I would probably try to avoid a setup like that. (Not saying that I'm dead set against the availability of VRRP for IPv6, though.) On 25 dec 2007, at 11:24, [EMAIL PROTECTED] wrote: since for reasons passing understanding, DHCP6 specifically won't do gateway assignment. For those of us with lots of IPv4 customers dependent on DHCP, it would be good to know more detail about this point. What is the problem, and are there plans to do anything about it in DHCPv6? It looks like many people working on DHCP for IPv6 favor a model where there is a separation of tasks between RAs and DHCPv6. So one does one thing, the other does something else. No overlap. Now I don't subscribe to that philosophy, because I want my hosts to learn their DNS servers from RAs (and finally we have RFC 5006!) but in this case I agree: there is no good way to make sure that what a DHCP server says is actually working, while a router advertising its own presence obviously does that. Address configuration and everything associated with it is the place where IPv4 and IPv6 are really different, so don't try to copy existing stuff in this area to IPv6 blindly, more often than not that's not the most optimal approach. There are actually some people asking for default gateways in DHCPv6. If this happens, it should be such that a DHCPv6 server can tell you which of the available gateways to prefer, but nothing stronger than that.
Re: v6 subnet size for DSL leased line customers
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. Okay, here's a problem. You keep making these statements which bear no resemblance to the real world. If I need more than 256 subnets, and I approach my ISP to ask for such, there are at least two obvious answers which are incredibly more likely than any risk of assign[ing] them[me] multiple noncontiguous prefixes. Answer 1: We don't provide more space on your Cableco Cable Modem Service. If you would like, we do offer Cableco Business Class Service. Answer 2: We can assign you a larger prefix, however, you'll need to power cycle the cable modem and your addresses will change. Remember, this is residential broadband. Saying /no/ is fairly common (in the same way that I can't get custom PTR DNS for a static IP address on a resi connection with many service providers.) 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. Yeah, well, I'm not impressed. As an operator community, we've been so good about getting our own affairs in order there. 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. How about /not/ upgrading all of your routers and keeping the $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 transitequipment 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. Customers at the low end of the spectrum do in fact care, and my guess would be that they'd rather save the nickel than get extra address space that only 1 in 1,000 of them might ever get around to using. 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. Ah! That's good. Now we're making some progress. The first question most businesses have when they're spending money is how much is it. Not how much is it on a per-customer basis. If I go and ask for a new $2000 server so that I can put up some neat new thing, such as a reverse-traceroute webserver, the idea is that I should need to justify why it can't be done on an existing webserver. Maybe it can, but maybe it can't (let's say because it'll connect out to our routers and the security risk warrants a separate server). The fact that it might only cost a penny per month per customer is irrelevant to the higher-level analysis. In the same way, if an ISP can avoid spending money, there are almost certainly some who will do so. Since the average customer is likely to be more than adequately served by 256 subnets for the foreseeable future, there will undoubtedly be some that allocate /56's (or even /64's). Market pressures, the actual needs of consumers, and whether or
Re: v6 subnet size for DSL leased line customers
Wow, is this what you folks do at Christmas ? -- Leigh Joe Greco wrote: 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. Okay, here's a problem. You keep making these statements which bear no resemblance to the real world. If I need more than 256 subnets, and I approach my ISP to ask for such, there are at least two obvious answers which are incredibly more likely than any risk of assign[ing] them[me] multiple noncontiguous prefixes. Answer 1: We don't provide more space on your Cableco Cable Modem Service. If you would like, we do offer Cableco Business Class Service. Answer 2: We can assign you a larger prefix, however, you'll need to power cycle the cable modem and your addresses will change. Remember, this is residential broadband. Saying /no/ is fairly common (in the same way that I can't get custom PTR DNS for a static IP address on a resi connection with many service providers.) 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. Yeah, well, I'm not impressed. As an operator community, we've been so good about getting our own affairs in order there. 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. How about /not/ upgrading all of your routers and keeping the $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 transitequipment 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. Customers at the low end of the spectrum do in fact care, and my guess would be that they'd rather save the nickel than get extra address space that only 1 in 1,000 of them might ever get around to using. 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. Ah! That's good. Now we're making some progress. The first question most businesses have when they're spending money is how much is it. Not how much is it on a per-customer basis. If I go and ask for a new $2000 server so that I can put up some neat new thing, such as a reverse-traceroute webserver, the idea is that I should need to justify why it can't be done on an existing webserver. Maybe it can, but maybe it can't (let's say because it'll connect out to our routers and the security risk warrants a separate server). The fact that it might only cost a penny per month per customer is irrelevant to the higher-level analysis. In the same way, if an ISP can avoid spending money, there are almost certainly some who will do so. Since the average customer is likely to be more than adequately served by 256 subnets for the foreseeable future, there will undoubtedly be some that allocate /56's (or
Re: v6 subnet size for DSL leased line customers
Leigh Porter wrote: Wow, is this what you folks do at Christmas ? Clearly you yourself are affectionate about this thing called Christmas, if you are so affectionate about it, then why are you making silly comments which do not contribute at all to the topic at hand? Must be very boring that Christmas of yours. On a more operational topic: even during Christmas (that Coca Cola induced commercialism party that gets attributed to some religion), people are using the Internet, and stuff breaks on the Internet, as such there will always be people who have to work on days like this. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: v6 subnet size for DSL leased line customers
LOL.. Yeah, I am on call today - thankfully nothing happened. Anyway, I hope you had a peaceful day! -- Leigh Crawford, Scott wrote: Well, I guess he told you. :) Merry Christmas Scotte -Original Message- From: Jeroen Massar [EMAIL PROTECTED] To: Leigh Porter [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: 07/12/25 11:48 AM Subject: Re: v6 subnet size for DSL leased line customers Leigh Porter wrote: Wow, is this what you folks do at Christmas ? Clearly you yourself are affectionate about this thing called Christmas, if you are so affectionate about it, then why are you making silly comments which do not contribute at all to the topic at hand? Must be very boring that Christmas of yours. On a more operational topic: even during Christmas (that Coca Cola induced commercialism party that gets attributed to some religion), people are using the Internet, and stuff breaks on the Internet, as such there will always be people who have to work on days like this. Greets, Jeroen
Re: v6 subnet size for DSL leased line customers
Thus spake [EMAIL PROTECTED] 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. For those of us with lots of IPv4 customers dependent on DHCP, it would be good to know more detail about this point. What is the problem, and are there plans to do anything about it in DHCPv6? For most hosts, there is no need for anything like VRRP or getting a default gateway via DHCP in v6 because all hosts are required to implement RA/RS. The vast majority of hosts either have one default gateway or two-plus equivalent ones, so that works fine. For hosts with multiple gateways that are unequal, VRRP+DHCP doesn't solve the problem any better than RA/RS; you have to fiddle with the hosts' routing tables to get things set up right. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: v6 subnet size for DSL leased line customers
Joel Jaeggli wrote: equipment makers (as much as randy hates them) excuse?!?!? that is unjustified and uncalled for. vendors, like everyone else, will do what is in their best interests. as i am an operator, not a vendor, that is often not what is in my best interest, marketing literature aside. i believe it benefits the ops community to be honest when the two do not seem to coincide. randy
RE: v6 subnet size for DSL leased line customers
Yep, it is sure little or no maintenance is being performed. :) John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leigh Porter Sent: Tuesday, December 25, 2007 4:06 PM To: Crawford, Scott Cc: nanog@merit.edu Subject: Re: v6 subnet size for DSL leased line customers LOL.. Yeah, I am on call today - thankfully nothing happened. Anyway, I hope you had a peaceful day! -- Leigh Crawford, Scott wrote: Well, I guess he told you. :) Merry Christmas Scotte -Original Message- From: Jeroen Massar [EMAIL PROTECTED] To: Leigh Porter [EMAIL PROTECTED] Cc: nanog@merit.edu Sent: 07/12/25 11:48 AM Subject: Re: v6 subnet size for DSL leased line customers Leigh Porter wrote: Wow, is this what you folks do at Christmas ? Clearly you yourself are affectionate about this thing called Christmas, if you are so affectionate about it, then why are you making silly comments which do not contribute at all to the topic at hand? Must be very boring that Christmas of yours. On a more operational topic: even during Christmas (that Coca Cola induced commercialism party that gets attributed to some religion), people are using the Internet, and stuff breaks on the Internet, as such there will always be people who have to work on days like this. Greets, Jeroen
Re: v6 subnet size for DSL leased line customers
Randy Bush wrote: Joel Jaeggli wrote: equipment makers (as much as randy hates them) excuse?!?!? that is unjustified and uncalled for. vendors, like everyone else, will do what is in their best interests. as i am an operator, not a vendor, that is often not what is in my best interest, marketing literature aside. i believe it benefits the ops community to be honest when the two do not seem to coincide. If the ops community doesn't provide enough addresses and a way to use them then the vendors will do the same thing they did in v4. It's not clear to me where their needs don't coincide in this case. there are three legs to the tripod network operator user equipment manufacturer They have (or should have) a mutual interest in: Transparent and automatic configuration of devices. The assignment of globally routable addresses to internet connected devices the user having some control over what crosses the boundry between their network and the operators. randy
Re: v6 subnet size for DSL leased line customers
Tony Li wrote: Randy's attitude that vendor's are all unequivocally evil please read what i said, and not what joel, very incorrectly, said what i said. then apologize. randy
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 transitequipment 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
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. cut How high are your transitequipment 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
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
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 transitequipment 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
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 transitequipment 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
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
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
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
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
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
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
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 well intentioned troll 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
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 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
On Sun, 23 Dec 2007, Iljitsch van Beijnum wrote: On 22 dec 2007, at 21:23, Ross Vandegrift wrote: 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. In fact, until I read the ARIN documents to receive an assignment at work, I assumed this would be how people would operate. So what's the concern? Give all end users a /64 and let them subnet that as they see fit. If DHCPv6 would take care of it automatically with shorter prefixes, that's fine First of all, there's RFC 3513: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. Second, we currently have two mechanisms to configure IPv6 hosts with an address: router advertisements and DHCPv6. The former has been implemented in ALL IPv6 stacks but doesn't work if your subnet isn't a /64. The latter is (I think) available on the client side in Windows Vista. There are a few DHCPv6 server implementations, but the ones I tested 2 years ago wouldn't do address assignment. (You still need the router advertisements to learn your default gateway and prefix length as DHCPv6 can't tell you those.) So although many people want to stick to the DHCP model they know from IPv4, that's extremely hard to do with IPv6 the way things currently are. Actually we tested DHCv6 implementation 2-3 years ago. http://www.6net.org/publications/deliverables/D3.2.3v3.pdf The dibbler seemed to be rather complete DHCPv6 implementation. I think default gateway and prefix length distribution via DHCPv6 will be quite problematical any many situation. 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 Best Regards, Janos Mohacsi
Re: v6 subnet size for DSL leased line customers
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 well intentioned troll 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? randy
Re: v6 subnet size for DSL leased line customers
On Sun, Dec 23, 2007 at 12:24:32AM +0100, Iljitsch van Beijnum wrote: First of all, there's RFC 3513: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. Ahhh, thanks - that is the only thing I have ever seen that gives any reason for the /64 prefix. Sadly, the document contains no compelling technical reasons for it - looks like it's done just so things are easy when generating interface IDs from ethernet addresses. Second, we currently have two mechanisms to configure IPv6 hosts with an address: router advertisements and DHCPv6. The former has been implemented in ALL IPv6 stacks but doesn't work if your subnet isn't a /64. But the protocols don't imply or require this. All of the messages used in stateless autoconfig will behave as expected with longer prefix lengths. So it seems that because the interface identifier has to be 64-bits, stateless autoconfig is unnecessarily crippled. For kicks I just tried RAs with a /96 prefix. Linux 2.6 checks and enforces the requirement from RFC3513, though it'd be trivial to change. But I'm guessing other vendors enforce this as well. -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
Re: v6 subnet size for DSL leased line customers
* Joe Greco: Right now, we might say wow, 256 subnets for a single end-user... hogwash! and in years to come, wow, only 256 subnets... what were we thinking!? Well, what's the likelihood of the only 256 subnets problem? There's a tendency to move away from (simulated) shared media networks. One host per subnet might become the norm.
Re: v6 subnet size for DSL leased line customers
Ross Vandegrift [EMAIL PROTECTED] writes: Ahhh, thanks - that is the only thing I have ever seen that gives any reason for the /64 prefix. Sadly, the document contains no compelling technical reasons for it - looks like it's done just so things are easy when generating interface IDs from ethernet addresses. One good guess for the rationale is to preserve the possibility of splitting the host and network identifier namespaces, like XNS and some others do. Should it be deemed the way forward, the current policy makes it slightly more of a possibility to decouple them after the fact.
Re: v6 subnet size for DSL leased line customers
Once upon a time, Florian Weimer [EMAIL PROTECTED] said: Right now, we might say wow, 256 subnets for a single end-user... hogwash! and in years to come, wow, only 256 subnets... what were we thinking!? Well, what's the likelihood of the only 256 subnets problem? There's a tendency to move away from (simulated) shared media networks. One host per subnet might become the norm. So each host will end up with a /64? How exactly are end-users expected to manage this? Having a subnet for the kitchen appliances and a subnet for the home theater, both of which can talk to the subnet for the home computer(s), but not to each other, will be far beyond the abilities of the average home user. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: v6 subnet size for DSL leased line customers
-- On Sun, 12/23/07, Chris Adams [EMAIL PROTECTED] wrote: From: Chris Adams [EMAIL PROTECTED] Subject: Re: v6 subnet size for DSL leased line customers To: nanog@merit.edu Date: Sunday, December 23, 2007, 2:21 PM Once upon a time, Florian Weimer [EMAIL PROTECTED] said: Right now, we might say wow, 256 subnets for a single end-user... hogwash! and in years to come, wow, only 256 subnets... what were we thinking!? Well, what's the likelihood of the only 256 subnets problem? There's a tendency to move away from (simulated) shared media networks. One host per subnet might become the norm. So each host will end up with a /64? How exactly are end-users expected to manage this? Having a subnet for the kitchen appliances and a subnet for the home theater, both of which can talk to the subnet for the home computer(s), but not to each other, will be far beyond the abilities of the average home user. As I see it, one of the big benefits IPv4 provided was logical addresssing in an easy-to-understand and easy-to-aggregate manner, with small layer-2 networks divided by routers. What we've gone to with IPv6 is a gigantic layer-2 network (the flat autoconfiguration space). I think we got here when site-local went away - we've effectively redefined link-local to mean site-local, while using globally unique addressing. Personally, I don't relish the idea of millions of hosts participating in spanning-tree, so I'd rather see us move back toward the direction of using layer-3 addresses to break up layer-2 islands. How about this for a modest proposal for a capability: Allow autoconfigured generation of IPv6 interface addresses to use this format: (one byte VLAN ID) (48 bit MAC address) instead of: (24 bit half-mac) (FFFE) (24 bit half-MAC) This would allow a CPE router to serve as the gateway for up to 64K VLANs, and wouldn't waste a byte in the middle of the address space. How about it? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: v6 subnet size for DSL leased line customers
There is a huge detent at /48, but there's a certain amount of guidance that can only be derived from operational experience. It's not clear to me why /56 would be unacceptable, particularly if you're delegating them to a device that already has a /64. Are one's customers attached via point-to-point links, or do they sit on shared broadcast domain where their cpe is receiving a /128 and requesting pd from the outset? When someone plugs an apple airport into a segment of the corporate lan should it be be able to request pd under those circumstances as well? how is that case different than plugging it in on a residential connection? These are issues providers can and should grapple with. More likely, at least some of them are fairly naive questions. For example, /experience/ tells us that corporate LAN policies are often implemented without regard to what we, as Internet engineers, would prefer, so I can guarantee you with a 100% certainty that there will be at least some networks, and more than likely many networks, where you will not be able to simply request a prefix delegation and have that work the way you'd like. There will always be some ISP who has delegated, or some end site who has received, a far too close to being just large enough allocation, and so even if we assume that every router vendor and IPv6 implementation from here to eternity has no knobs to disable prefix delegation, simple prefix exhaustion within an allocation will be a problem. All the screams of but they should have been allocated more will do nothing to change this. Further, if we consider, for a moment, a world where prefix delegation is the only method of adding something like an Apple Airport to an existing network, this is potentially encouraging the burning of /64's for the addition of a network with perhaps a single client. That's perfectly fine, /as long as/ networks are allocated sufficient resources. This merely means that from a fairly pessimistic viewpoint, IPv6 is actually a 64-bit address space for purposes of determining how much address space is required. So, from the point of view of someone manufacturing devices to attach to IPv6 networks, I have some options. I can: 1) Assume that DHCP PD is going to work, and that the end user will have a prefix to delegate, which might be valid or it might not. This leaves me in the position of having to figure out a backup strategy, because I do not want users returning my device to Best Buy because it don't work. The backup strategy is bridging. 2) Assume that DHCP PD is not going to work, and make bridging the default strategy. DHCP PD can optionally be a configurable thing, or autodetect, or whatever, but it will not be mandatory. I am being facetious here, of course, since only one of those is really viable in the market. Anyone who thinks otherwise is welcome to explain to me what's going to happen in the case where there are no P's to D. I will leave the difference between corporate and residential as an exercise to the reader; suffice it to say that the answers are rather obvious in the same manner. ... 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
On Sun, 23 Dec 2007 12:54:34 -0500 Ross Vandegrift [EMAIL PROTECTED] wrote: On Sun, Dec 23, 2007 at 12:24:32AM +0100, Iljitsch van Beijnum wrote: First of all, there's RFC 3513: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. Ahhh, thanks - that is the only thing I have ever seen that gives any reason for the /64 prefix. Sadly, the document contains no compelling technical reasons for it - looks like it's done just so things are easy when generating interface IDs from ethernet addresses. If operational simplicity of fixed length node addressing is a technical reason, then I think it is a compelling one. If you've ever done any reasonable amount of work with Novell's IPX (or other fixed length node addressing layer 3 protocols (mainly all of them except IPv4!)) you'll know what I mean. I think Ethernet is also another example of the benefits of spending/wasting address space on operational convenience - who needs 46/47 bits for unicast addressing on a single layer 2 network!? If I recall correctly from bits and pieces I've read about early Ethernet, the very first versions of Ethernet only had 16 bit node addressing. They then decided to spend/waste bits on addressing to get operational convenience - plug and play layer 2 networking. If IPv6 can have the same operational simplicity as Ethernet, and addressing bits can afford to be spent on it, then I think those bits are well worth spending. The /64 for all subnets idea is probably an example of worse is better principle. It's not ideal for everything, but because it's general enough, it works with everything, and is simpler and a *single* solution to everything, and that's what makes it better. Regarding where the /64 boundary came from, from what I understand, the following Internet Drafts are it's origin: 8+8 - An Alternate Addressing Architecture for IPv6 http://arneill-py.sacramento.ca.us/ipv6mh/draft-odell-8+8-00.txt GSE - An Alternate Addressing Architecture for IPv6 http://arneill-py.sacramento.ca.us/ipv6mh/draft-ipng-gseaddr-00.txt Second, we currently have two mechanisms to configure IPv6 hosts with an address: router advertisements and DHCPv6. The former has been implemented in ALL IPv6 stacks but doesn't work if your subnet isn't a /64. But the protocols don't imply or require this. All of the messages used in stateless autoconfig will behave as expected with longer prefix lengths. So it seems that because the interface identifier has to be 64-bits, stateless autoconfig is unnecessarily crippled. For kicks I just tried RAs with a /96 prefix. Linux 2.6 checks and enforces the requirement from RFC3513, though it'd be trivial to change. But I'm guessing other vendors enforce this as well. -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
On Sun, 23 Dec 2007 19:46:26 +0100 Florian Weimer [EMAIL PROTECTED] wrote: * Joe Greco: Right now, we might say wow, 256 subnets for a single end-user... hogwash! and in years to come, wow, only 256 subnets... what were we thinking!? Well, what's the likelihood of the only 256 subnets problem? There's a tendency to move away from (simulated) shared media networks. One host per subnet might become the norm. Or possibly maybe Peter M. Gleitz's and Steven M. Bellovin's idea of Transient Addressing for Related Processes: Improved Firewalling by Using IPV6 and Multiple Addresses per Host http://www.cs.columbia.edu/~smb/papers/tarp/tarp.html A /64 per host is probably not necessary, however if an end-site has a /48, that's 65K hosts so it wouldn't likely be much of a problem for most sites ... certainly not my house currently or in the forseeable future or my current employer, or most employers I've worked for in the past. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
Once upon a time, Florian Weimer [EMAIL PROTECTED] said: Right now, we might say wow, 256 subnets for a single end-user... hogwash! and in years to come, wow, only 256 subnets... what were we thinking!? Well, what's the likelihood of the only 256 subnets problem? There's a tendency to move away from (simulated) shared media networks. One host per subnet might become the norm. So each host will end up with a /64? That's a risk. It is more like each host might end up with a /64. Now, the thing here is, there's nothing wrong with one host per subnet. There's just something wrong with blowing a /64 per subnet in an environment where you have one host per subnet, and a limited amount of bits above /64 (you essentially have /unlimited/ addresses within the /64, but an ISP may be paying for space, etc). Now, understand, I /like/ the idea of /64 networks in general, but I do have concerns about where the principle breaks down. If we're agreed to contemplate IPv6 as being a 64-bit address space, and then allocating space on that basis, I would suggest that some significant similarities to IPv4 appear. In particular, a NAT gateway for IPv4 translates fairly well into a subnet-on-a-/64 in IPv6. That is interesting, but it may not actually reduce the confusion as to how to proceed. How exactly are end-users expected to manage this? Having a subnet for the kitchen appliances and a subnet for the home theater, both of which can talk to the subnet for the home computer(s), but not to each other, will be far beyond the abilities of the average home user. Well, this gets back to what I was saying before. At a certain point, Joe Sixpack might become sophisticated enough to have an electrician come in and run an ethernet cable from the jack on the fridge to his home router. He might also be sophisticated enough to pay $ElectronicsStore installation dep't to run an ethernet cable from the jack on the home theater equipment to the home router. I believe that this may in fact have come to pass ... Now the question is, what should happen next. The L3 option is that the home router presents a separate /64 on each port, and offers some firewalling capabilities. I hinted before that I might not be thrilled with this, due to ISP commonly controlling CPE, but that can be addressed by making the router separate. There's a trivial L2 option as well. You can simply devise a L2 switch that implements filtering policies. Despite all the cries of that's not how we do it in v4! and we can't change the paradigm, the reality is that this /could/ be perfectly fine. As a matter of fact, for Joe Sixpack, it almost certainly /is/ fine. Joe Sixpack's policy is going to read just like what you wrote above. subnet for appliances, subnet for computer, subnet for theater, with the appliances and theater only being able to talk to computer. He's not going to care if it's an actual subnet or just a logical blob. This is easy to do at L2 or L3. We're more /used/ to doing it at L3, but it's certainly workable at L2, and the interface to do so doesn't necessarily even need to look any different, because Joe Sixpack does not care about the underlying network topology and strategy. I would absolutely like to see DHCP PD be usable for environments where multiple prefixes are available and allowed, but I believe we're going to also be needing to look at bridging. There's /going/ to be some crummy ISP somewhere that only allocates end users a /64, or there's /going/ to be a business with a network that will refuse DHCP PD, and as a result there /will/ be a market for devices that have the ability to cope. ... 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
If operational simplicity of fixed length node addressing is a technical reason, then I think it is a compelling one. If you've ever done any reasonable amount of work with Novell's IPX (or other fixed length node addressing layer 3 protocols (mainly all of them except IPv4!)) you'll know what I mean. I think Ethernet is also another example of the benefits of spending/wasting address space on operational convenience - who needs 46/47 bits for unicast addressing on a single layer 2 network!? If I recall correctly from bits and pieces I've read about early Ethernet, the very first versions of Ethernet only had 16 bit node addressing. They then decided to spend/waste bits on addressing to get operational convenience - plug and play layer 2 networking. The difference is that it doesn't cost anything. There are no RIR fees, there is no justification. You don't pay for, or have to justify, your Ethernet MAC addresses. With IPv6, there are certain pressures being placed on ISP's not to be completely wasteful. This will compel ISP's to at least consider the issues, and it will most likely force users to buy into technologies that allow them to do what they want. And inside a /64, you have sufficient space that there's probably nothing you can't do. :-) ... 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
I think we got here when site-local went away - we've effectively redefined link-local to mean site-local, while using globally unique addressing. site-local was replaced with ULA. Have you got your ULA yet? :-) ULA gives you /48's. 6to4 gives you /48's. Your customers already have /48's whether they know it or not (and some do). Mark
Re: v6 subnet size for DSL leased line customers
On Sun, 23 Dec 2007 17:26:12 -0600 (CST) Joe Greco [EMAIL PROTECTED] wrote: If operational simplicity of fixed length node addressing is a technical reason, then I think it is a compelling one. If you've ever done any reasonable amount of work with Novell's IPX (or other fixed length node addressing layer 3 protocols (mainly all of them except IPv4!)) you'll know what I mean. I think Ethernet is also another example of the benefits of spending/wasting address space on operational convenience - who needs 46/47 bits for unicast addressing on a single layer 2 network!? If I recall correctly from bits and pieces I've read about early Ethernet, the very first versions of Ethernet only had 16 bit node addressing. They then decided to spend/waste bits on addressing to get operational convenience - plug and play layer 2 networking. The difference is that it doesn't cost anything. There are no RIR fees, there is no justification. You don't pay for, or have to justify, your Ethernet MAC addresses. With IPv6, there are certain pressures being placed on ISP's not to be completely wasteful. I don't think there is that difference at all. MAC address allocations are paid for by the Ethernet chipset/card vendor, and I'm pretty sure they have to justify their usage before they're allowed to buy another block. I understand they're US$1250 an OUI, so something must have happened to prevent somebody buying them all up to hoard them, creating artificial scarcity, and then charging a market sensitive price for them, rather than the flat rate they cost now. That's not really any different to an ISP paying RIR fees, and then indirectly passing those costs onto their customers. This will compel ISP's to at least consider the issues, and it will most likely force users to buy into technologies that allow them to do what they want. And inside a /64, you have sufficient space that there's probably nothing you can't do. :-) ... 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. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
There's a tendency to move away from (simulated) shared media networks. One host per subnet might become the norm. and, with multiple addresses per interface, the home user surely _might_ need a /32. sigh might does not make right randy
Re: v6 subnet size for DSL leased line customers
I think Ethernet is also another example of the benefits of spending/wasting address space on operational convenience - who needs 46/47 bits for unicast addressing on a single layer 2 network!? If I recall correctly from bits and pieces I've read about early Ethernet, the very first versions of Ethernet only had 16 bit node addressing. They then decided to spend/waste bits on addressing to get operational convenience - plug and play layer 2 networking. The difference is that it doesn't cost anything. There are no RIR fees, there is no justification. You don't pay for, or have to justify, your Ethernet MAC addresses. With IPv6, there are certain pressures being placed on ISP's not to be completely wasteful. I don't think there is that difference at all. MAC address allocations are paid for by the Ethernet chipset/card vendor, and I'm pretty sure they have to justify their usage before they're allowed to buy another block. I understand they're US$1250 an OUI, so something must have happened to prevent somebody buying them all up to hoard them, creating artificial scarcity, and then charging a market sensitive price for them, rather than the flat rate they cost now. That's not really any different to an ISP paying RIR fees, and then indirectly passing those costs onto their customers. MAC address allocations are paid for by the Ethernet chipset/card vendor. They're not paid for by an ISP, or by any other Ethernet end-user, except as a pass-through, and therefore it's considered a fixed cost. There are no RIR fees, and there is no justification. You buy a gizmo with this RJ45 and you get a unique MAC. This is simple and straightforward. If you buy one device, you get one MAC. If you buy a hundred devices, you get one hundred MAC's. Not 101, not 99. This wouldn't seem to map well at all onto the IPv6 situation we're discussing. With an IPv6 prefix, it is all about the prefix size. Since a larger allocation may cost an ISP more than a smaller allocation, an ISP may decide that they need to charge a customer who is allocated a /48 more than a customer who is allocated a /64. I don't pay anyone anything for the use of the MAC address I got on this free ethernet card someone gave me, yet it is clearly and unambiguously mine (and only mine) to use. Does that clarify things a bit? If you are proposing that RIR's cease the practice of charging different amounts for different allocation sizes, please feel free to shepherd that through the approvals process, and then I will certainly agree that there is no longer a meaningful cost differential for the purposes of this discussion. Otherwise, let's not pretend that they're the same thing, since they're clearly not. ... 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
On Sun, 23 Dec 2007 19:27:55 -0600 (CST) Joe Greco [EMAIL PROTECTED] wrote: I think Ethernet is also another example of the benefits of spending/wasting address space on operational convenience - who needs 46/47 bits for unicast addressing on a single layer 2 network!? If I recall correctly from bits and pieces I've read about early Ethernet, the very first versions of Ethernet only had 16 bit node addressing. They then decided to spend/waste bits on addressing to get operational convenience - plug and play layer 2 networking. The difference is that it doesn't cost anything. There are no RIR fees, there is no justification. You don't pay for, or have to justify, your Ethernet MAC addresses. With IPv6, there are certain pressures being placed on ISP's not to be completely wasteful. I don't think there is that difference at all. MAC address allocations are paid for by the Ethernet chipset/card vendor, and I'm pretty sure they have to justify their usage before they're allowed to buy another block. I understand they're US$1250 an OUI, so something must have happened to prevent somebody buying them all up to hoard them, creating artificial scarcity, and then charging a market sensitive price for them, rather than the flat rate they cost now. That's not really any different to an ISP paying RIR fees, and then indirectly passing those costs onto their customers. MAC address allocations are paid for by the Ethernet chipset/card vendor. They're not paid for by an ISP, or by any other Ethernet end-user, except as a pass-through, and therefore it's considered a fixed cost. There are no RIR fees, and there is no justification. You buy a gizmo with this RJ45 and you get a unique MAC. This is simple and straightforward. If you buy one device, you get one MAC. If you buy a hundred devices, you get one hundred MAC's. Not 101, not 99. This wouldn't seem to map well at all onto the IPv6 situation we're discussing. How many ISP customers pay RIR fees? Near enough to none, if not none. I never have when I've been an ISP customer. Why are you pretending they do? I think your taking an end-user perspective when discussing ethernet but an RIR fee paying ISP position when discussing IPv6 subnet allocations. That's not a valid argument, because you've changed your viewpoint on the situation to suit your position. Anyway, the point I was purely making was that if you can afford to spend the bits, because you have them (as you do in Ethernet by design, as you do in IPv6 by design, but as you *don't* in IPv4 by design), you can spend them on operational convenience for both the RIR paying entity *and* the end-user/customer. Unnecessary complexity is *unnecessary*, and your customers won't like paying for it if they discover you've chosen to create it either on purpose or through naivety. With an IPv6 prefix, it is all about the prefix size. Since a larger allocation may cost an ISP more than a smaller allocation, an ISP may decide that they need to charge a customer who is allocated a /48 more than a customer who is allocated a /64. I don't pay anyone anything for the use of the MAC address I got on this free ethernet card someone gave me, yet it is clearly and unambiguously mine (and only mine) to use. Does that clarify things a bit? If you are proposing that RIR's cease the practice of charging different amounts for different allocation sizes, please feel free to shepherd that through the approvals process, and then I will certainly agree that there is no longer a meaningful cost differential for the purposes of this discussion. Otherwise, let's not pretend that they're the same thing, since they're clearly not. ... 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. -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
On Mon, 24 Dec 2007 09:58:44 +0900 Randy Bush [EMAIL PROTECTED] wrote: There's a tendency to move away from (simulated) shared media networks. One host per subnet might become the norm. and, with multiple addresses per interface, the home user surely _might_ need a /32. What prompted you to suggest that? Trolling maybe? might does not make right Neither does being ridiculous. randy -- Sheep are slow and tasty, and therefore must remain constantly alert. - Bruce Schneier, Beyond Fear
Re: v6 subnet size for DSL leased line customers
MAC address allocations are paid for by the Ethernet chipset/card vendor. They're not paid for by an ISP, or by any other Ethernet end-user, except as a pass-through, and therefore it's considered a fixed cost. There are no RIR fees, and there is no justification. You buy a gizmo with this RJ45 and you get a unique MAC. This is simple and straightforward. If you buy one device, you get one MAC. If you buy a hundred devices, you get one hundred MAC's. Not 101, not 99. This wouldn't seem to map well at all onto the IPv6 situation we're discussing. How many ISP customers pay RIR fees? Near enough to none, if not none. Who said anything about ISP customers paying RIR fees? Although they certainly do, indirectly. I never have when I've been an ISP customer. (Must be one of those legacy ISP's?) Why are you pretending they do? I don't recall bringing them into the discussion, BUT... I think your taking an end-user perspective when discussing ethernet but an RIR fee paying ISP position when discussing IPv6 subnet allocations. That's not a valid argument, because you've changed your viewpoint on the situation to suit your position. Oddly enough, I'm one of those rare people who've worked with both ISP's and OEM's that have been assigned MAC's. You can think as you wish, and you're wrong. Anyway, the point I was purely making was that if you can afford to spend the bits, because you have them (as you do in Ethernet by design, as you do in IPv6 by design, but as you *don't* in IPv4 by design), you can spend them on operational convenience for both the RIR paying entity *and* the end-user/customer. Unnecessary complexity is *unnecessary*, and your customers won't like paying for it if they discover you've chosen to create it either on purpose or through naivety. Okay, here, let me make it reaaally simple. If I am going out and buying an Ethernet card today, the mfr will pay $.NN for my MAC address, a cost that is built into the retail cost of the card. It will never be more or less than $.NN, because the number of MAC addresses assigned to my card is 1. Always 1. Always $.NN. If I am going out and buying IPv6 service today, the ISP will pay a variable amount for my address space. The exact amount is a function of their own delegation size (you can meander on over to ARIN yourself) and the size they've delegated to you; and so, FOR PURPOSES OF ILLUSTRATION, consider this. 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. If your ISP has been delegated a /48 (admittedly unlikely, but possible) for $1,250/year, and they assign you a /48, their cost to provide that space is ~$1,250. They can have 1 such customer. If your ISP has been delegated a /41, for $1,250/year, and they assign you a /48, their cost to provide that space is ~$10. They can have 128 such customers. There is a significant variation in pricing as the parameters are changed. You do not just magically have free bits in IPv6 by design; the ISP is paying for those bits. There will be factors MUCH more real than whether or not customers like paying for it if they discover you've chosen to create [complexity], because quite frankly, residential end users do not typically have a clue, and so even if you do tick off 1% who have a clue, you're still fine. Now, seriously, just who do you think is paying for the space? And if $competitor down the road is charging rock bottom prices for Internet access, how much money does the ISP really want to throw at extra address space? (Do you want me to discuss naivety now?) And just /how/ is this in any way similar to Ethernet MAC addresses, again? Maybe I'm just too slow and can't see how fixed cost == variable cost. I won't accept any further hand-waving as an answer, so to continue, please provide solid examples, as I've done. Perhaps more on-topic, how many IP addresses can dance on the head of a /64? ... 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
On Dec 23, 2007 8:44 PM, Randy Bush [EMAIL PROTECTED] wrote: and trying to keep 50k machines updated with proper resolvers (in the simplest example) is easier with RA than DHCP how? do you really mean skip RA or all of autoconf? I think what makes sense is to use the parts of ipv6 that work well, RA, but blend in what works already well and is folded already into the enterprise model... dhcpv6. i want to explore RA(only) + DHCP, to save me from running a routing protocol or vsrp to have redundant exits for a LAN. ok, somewhere there's a blend of things that will work for enterprises and cable/dsl/mso folk. I think that some enterprises don't mind 'random address selection' while they want to pass out info required (cause like it or not DNS is required) in a sane manner, one that's even part of their current method. 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. Basically my rant here is that autoconf isn't enough, it's not even a starting point for enterprise folks who rely on DHCP for all it's bells + whistles. Taking a giant leap backwards is never going to fly for them, so wake up and smell the cafe, dhcpv6 needs to be viable, workable, operable, built-in and well tested. randy, about to go off net, heading for a rural onsen ryokan have fun! -Chris
Re: v6 subnet size for DSL leased line customers
Joe Greco wrote: There is a huge detent at /48, but there's a certain amount of guidance that can only be derived from operational experience. It's not clear to me why /56 would be unacceptable, particularly if you're delegating them to a device that already has a /64. Are one's customers attached via point-to-point links, or do they sit on shared broadcast domain where their cpe is receiving a /128 and requesting pd from the outset? When someone plugs an apple airport into a segment of the corporate lan should it be be able to request pd under those circumstances as well? how is that case different than plugging it in on a residential connection? These are issues providers can and should grapple with. More likely, at least some of them are fairly naive questions. For example, /experience/ tells us that corporate LAN policies are often implemented without regard to what we, as Internet engineers, would prefer, so I can guarantee you with a 100% certainty that there will be at least some networks, and more than likely many networks, where you will not be able to simply request a prefix delegation and have that work the way you'd like. There will always be some ISP who has delegated, or some end site who has received, a far too close to being just large enough allocation, and so even if we assume that every router vendor and IPv6 implementation from here to eternity has no knobs to disable prefix delegation, simple prefix exhaustion within an allocation will be a problem. All the screams of but they should have been allocated more will do nothing to change this. Further, if we consider, for a moment, a world where prefix delegation is the only method of adding something like an Apple Airport to an existing network, this is potentially encouraging the burning of /64's for the addition of a network with perhaps a single client. That's perfectly fine, /as long as/ networks are allocated sufficient resources. This merely means that from a fairly pessimistic viewpoint, IPv6 is actually a 64-bit address space for purposes of determining how much address space is required. So, from the point of view of someone manufacturing devices to attach to IPv6 networks, I have some options. I can: 1) Assume that DHCP PD is going to work, and that the end user will have a prefix to delegate, which might be valid or it might not. This leaves me in the position of having to figure out a backup strategy, because I do not want users returning my device to Best Buy because it don't work. The backup strategy is bridging. 2) Assume that DHCP PD is not going to work, and make bridging the default strategy. DHCP PD can optionally be a configurable thing, or autodetect, or whatever, but it will not be mandatory. I am being facetious here, of course, since only one of those is really viable in the market. Anyone who thinks otherwise is welcome to explain to me what's going to happen in the case where there are no P's to D. 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. The current apple airport bridges v6 while natting ivp4 this is a perceived boundary problem in some circles and likely will be addressed in future software revision. I will leave the difference between corporate and residential as an exercise to the reader; suffice it to say that the answers are rather obvious in the same manner. ... JG
Re: v6 subnet size for DSL leased line customers
Joe Greco wrote: I'd say skip the /64 and /48. Don't do the /64, as future-proofing. A /48 is just something I cannot see need for, given the number of addresses available as a /56, unless the home user is actually providing connectivity to a bunch of his nearby friends and neighbors. Having fewer options is going to be easier for the ISP, I suspect. Not just the ISP, but the home user, and the designers of the devices for the home. As you point out, device configuration in the home needs to be as simple as possible. It would be nice if designers of new networked home devices (particularly those that that would like to use media types which might not be readily bridged to other common media types) could have some reasonable assurance up front that they have the option of an IPv6 subnet in the home to use. This would then be one less thing to try and automatically discover, ask the user to configure information about, develop a workaround for, etc. Less options is a very good thing here, and rampant /64s could well paint the device manufacturers into a corner on what tools IPv6 gives them to take advantage of. - Mark ... JG
Re: v6 subnet size for DSL leased line customers
On Dec 22, 2007 1:45 AM, Mark Townsley [EMAIL PROTECTED] wrote: Joe Greco wrote: I'd say skip the /64 and /48. Don't do the /64, as future-proofing. A /48 is just something I cannot see need for, given the number of addresses available as a /56, unless the home user is actually providing connectivity to a bunch of his nearby friends and neighbors. Having fewer options is going to be easier for the ISP, I suspect. Not just the ISP, but the home user, and the designers of the devices for the home. As you point out, device configuration in the home needs to be as simple as possible. It would be nice if designers of new networked home devices (particularly those that that would like to use media types which might not be readily bridged to other common media types) could have some reasonable assurance up front that they have the option of an IPv6 subnet in the home to use. This would then be one less thing to try and automatically discover, ask the user to configure information about, develop a workaround for, etc. Less options is a very good thing here, and rampant /64s could well paint the device manufacturers into a corner on what tools IPv6 gives them to take advantage of. can you expound some on the last part of this? the 'rampant /64's..' part? Since auto-conf pretty much requires the LAN to be /64 sized and if you believe more than 1 subnet would be of use to the end-user/residence then there are only a few options left, eh? It seems that the ppp-o-e sorts of connections could pass out this information and make the lives of equipment/user easier, what sort of options were you envisioning? (or what were you hoping to avoid?) I ask because I'm fairly certain the operator and standards-body folks both would be curious about a vendor's (or vendor-ish-person's view) view on this issue, I just don't think a rational answer is forthcoming from the 'user' community on this quite yet :( -Chris
Re: v6 subnet size for DSL leased line customers
On Sat, 22 Dec 2007 12:29:54 +0900 Randy Bush [EMAIL PROTECTED] wrote: simon, there are a million chances. and we are notoriously bad at predicting any of them more than a year or so out. In general, you're right. But we have ~60 years of experience teaching us that *every* successful computer architecture runs out of address space. I see no reason to think that today's models for home address space will be the exception (unless, of course, IPv6 is unsuccessful, but in that case it doesn't matter much what we do for allocation policy unless our actions are sufficiently stupid to cause the failure). --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: v6 subnet size for DSL leased line customers
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. In fact, until I read the ARIN documents to receive an assignment at work, I assumed this would be how people would operate. So what's the concern? Give all end users a /64 and let them subnet that as they see fit. If DHCPv6 would take care of it automatically with shorter prefixes, that's fine - I doubt it cares if it's doling out info for a /56, /64, or /96. Not like anything on the public internet is going to care a lick either. -- Ross Vandegrift [EMAIL PROTECTED] The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell. --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
