question about ipv6 prefix from ripe to ISP

[Ahmed M. H. Alzaeem]

hi ,
i request an ipv6 prefix from ripe , and they replied i can have /29 ------ /32 prefix  based on plan of deploying .

my question is ,  does the isp can own /32 ???
i think it is very much for isp to own /29 or /32 in ipv6 ???

i read a little and found that isps generally gets  /64 prefix .

plz advice  about my issue , >:(


regards

[kasperd]

i read a little and found that isps generally gets  /64 prefix .

I don't know where you read that. But that is entirely wrong. A /64 is the prefix you should assign to a single link. Each customer is supposed to get a prefix, which is shorter than a /64.

There is some disagreement on exactly how long a prefix you should give each customer. Originally it was supposed to be a /48, leaving 16 bits for the customer to organize their own network. But it is also possible to not give each customer a prefix until they ask for it, and only give them what they need.

You should ensure that the customer doesn't have to go through any work to get their prefix. Once the customer connects their IPv6 capable router, it will send a request to your DHCPv6 server asking for a prefix. A reasonable expectation is that most of those routers will ask for a /60. The segment on the outside of the customer's router could be a /64 shared between multiple customers, but it might be desirable to allocate a /64 per customer for that.

If a customer were to hook up multiple routers, you should have plenty of addresses for that, as long as each router doesn't request more than a /60. It is still going to be a lot less than a /48. I'd argue that the very minimum you should expect to allocate per customer would be a /58, which can be split into three /60s that can be delegated to the customer's routers, and 16 /64s of which half of them could be delegated to the customer's routers, one is used for the segment on the outside of the customer's routers, and the remaining seven are reserved.

This is the bare minimum to allocate per customer. You might want to allocate even more to keep things simpler. Additionally each customer should be able to allocate a single shorter prefix (48-56 bits). That one you can allocate on demand, such that you don't have to allocate those for every single customer. Those shorter prefixes could be where most of the addresses are spent. If 0.1% of your customers request a /48, then those alone are going to consume as many addresses as a /58 per customer.

If you did go with the 0.1%, then that would mean a /57 on average per customer. But I'd think that is setting yourself up for running out. Some people have suggested you should automatically give each customer a /56 and only give a /48 to business customers that have a network large enough to warrant such a short prefix.

A couple of examples of how the math could work out.

1. You have a /15 and a /16 IPv4 prefix, you'd need to have a /13 to be able to renumber into a single prefix and allow for a bit of growth. That would mean 19 bits to use for addressing within your network. Now if you want to give each customer a /48 IPv6 prefix and you still need 19 bits for addressing within your network, then subtract those two numbers to find you need a /29 IPv6 prefix rom RIPE.

2. You have a /12 and some /14 and longer IPv4 prefixes, you'd need to have a /10 to be able to renumber into a single prefix and allow for a bit of growth. That would mean 22 bits to use for addressing within your network. Now if you want to give each customer a /56 IPv6 prefix and a /48 to only those few that really need it, then you might need a /55 on average and still need 22 bits for addressing within your network. It would come out with you needing a /33 from RIPE. But RIPE is most likely not going to hand you such a long prefix, so you'd get a /32 anyway and allow you to grow (either by adding more customers or by giving a /48 to a larger percentage of the customers).

To do the math, you'll need two numbers. You'll need to know how large a prefix you'll give each customer on average. And I'd say that number will end up in the 48-55 bits range. And you'll need to know how many customers you expect to have about a year from now.

I don't know how large an ISP you run. The prefixes RIPE have handed out range from /19 for a really large ISP (RIPE have handed out two of those) to a /32 for a small ISP (RIPE have handed out more than 4000 of those).

As for the allocation of prefixes to individual routers, this document may be relevant: http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-11

Most of what I have written here may not be important to you yet. After all at the moment you are just trying to figure out one number, which is the length of the prefix to get from RIPE.

[tdensmore]

I wonder how IPv6 is ever going to make any headway when even addressing is such a difficult subject for even technical people to deal with.

People initially tend to look at IPv6 IPs and either panic or scratch their heads.  They are long meaningless strings to most people.  Add to that that most people consider "255.255.255.0" the number you use in any text-box that asks for a subnet. These subnets are referred to as "a class c" in most cases (though, TBH, I find pedantic rebuttal of that common usage much more irritating than the well-intentioned misuse). IPv6 is forcing folks to learn CIDR (though, I'm sure that'll eventually mean they know enough to believe that /64 is what you use for netmask everywhere).  Yow.

I understand that different service providers are going to make their own choices about prefix lengths for customer allocations.  I can't see that changing ever.  But when you have one crowd saying "/56, any more is insane and wasteful" and another saying "/48, anything else is broken v6 and you should vote with your wallet" and even a small minority saying "/64, it's our network, that's how we're rolling" (or whatever) it can be very confusing for, well, everyone.  The various books out there don't help this issue at all since examples are all over the place in terms of how things are applied.

Then you have cases like P2P links - /64?  /126?  /127? - and all the various arguments about why each choice is the "best" one.  Are people eventually going to regret having assigned /64s on P2Ps due to whatever resource exhaustion attack comes next?  IDK, but one camp says yes, and others say no.

I was under the impression that at least *most* of the IPv6 world was on board with subnetting at the nibble boundary, though.  Yet, frequently I see examples, like yours, where non-nibble prefixes are discussed.  I mean, honestly it's nothing at all to me, and shouldn't be anything at all to the rest of the world, if network A chooses to use /37s everywhere, but it can be extremely confusing to people just getting their feet wet.

Add all of that together, and just from an addressing POV, I can see why "Thanks, but I'd rather spend no additional money to get my network "IPv6Ready" and spend no additional money to train/learn, and I'll just continue to NAT - works great for me!" continues to be such a popular option.

[kasperd]

I wonder how IPv6 is ever going to make any headway when even addressing is such a difficult subject for even technical people to deal with.

Don't confuse difficulty with bikeshedding.

I'm sure that'll eventually mean they know enough to believe that /64 is what you use for netmask everywhere

For most users that is also sufficient. You really only need to know more than that, if you are a network administrator.

I understand that different service providers are going to make their own choices about prefix lengths for customer allocations.  I can't see that changing ever.  But when you have one crowd saying "/56, any more is insane and wasteful" and another saying "/48, anything else is broken v6 and you should vote with your wallet" and even a small minority saying "/64, it's our network, that's how we're rolling" (or whatever) it can be very confusing for, well, everyone.

Let's be realistic. Whether it is /48, /52, /56, or /60 doesn't matter. There are enough /48s that we are unlikely to run out of those. Even with a HD-ratio of only 80% that will cover 68 billion end user sites. And for most home users a /60 will be sufficient for many years to come. Even though I see myself as a power user, I still don't see myself using more than a handful of those 16 subnets I can get out of a /60.

I do say people should vote with their wallet. But if you are deciding between one ISP offering a /60 and one offering a /48, most likely there is some other more important difference between them. Currently just getting IPv6 in the first place is where I would vote with my wallet.

Then you have cases like P2P links - /64?  /126?  /127? - and all the various arguments about why each choice is the "best" one.  Are people eventually going to regret having assigned /64s on P2Ps due to whatever resource exhaustion attack comes next?

The only likely resource exhaustion to result from that is the memory usage for the neighbour table.

I was under the impression that at least *most* of the IPv6 world was on board with subnetting at the nibble boundary, though.

RIPE is handing out all sizes from /19 to /32. 95% of the allocations are /32. But the size accounting for the largest fraction of addresses is /19s. The two /19s that RIPE have handed out cover 41% of the addresses, which have been handed out by RIPE. (Source)

For prefixes longer than 32 bits, I think there is agreement to do subnetting on the nibble boundary.

Add all of that together, and just from an addressing POV, I can see why "Thanks, but I'd rather spend no additional money to get my network "IPv6Ready" and spend no additional money to train/learn, and I'll just continue to NAT - works great for me!" continues to be such a popular option.

That makes no sense. All the complexity you have been mentioning comes from people wanting to do the same thing they have gotten used to.

On one side you have people explaining that IPv6 addresses have three times as many bits as you are ever going to need. So you don't have to deal with all the complex addressing schemes that were used to conserve IPv4 addresses.

On the second side you have people saying they like the complexity and they want to keep it.

On the third side you have people listening to the first two sides arguing and saying this IPv6 stuff sounds way too complicated, let's just stick with IPv4.

On the fourth side you have people saying can't you guys start deploying IPv6 instead of arguing over something that doesn't matter at all?


The main lesson is. Worrying about prefix lengths and address conservation is for IPv4 only. Just don't make things harder for yourself by dealing with so many different prefix lengths. With IPv6 you should work with as few possible prefix lengths as you can. Running dual stack will add a little bit of complexity. Don't make it worse for no good reason.

Trying to conserve IPv6 addresses is something nobody should be doing as long as there are still people using IPv4. Once IPv4 is gone, we can start considering whether the IPv6 addressing plan needs to be made more complicated.

It is unlikely that 2000::/3 will ever run out. If it does happen I predict that 4000::/3 will be used in a much more conservative way. At that point I expect the assignments to end sites will be changed from /48 to /60, and subnets will be changed from /64 to /76.

[tdensmore]

To be clear, I wasn't talking about any exhaustion concerns.  I'm not sure what I believe about that other than it's hard to burn through a /3, sure, but much less hard to burn through a /32.

I also wasn't criticizing your post - it was a very good one.  Your example use of /57 and /58 prefix lengths got me thinking, though.

I was saying that until there's some really rock solid consensus about standard ways to deploy v6 and to make addressing and subnetting less frightening, I can't see a huge desire to change anything in many cases.  I have IPv6 available, at least in a basic form, on the small ISP network I help run/manage, and no one I've asked is interested in having v6 access since, currently at least, it's scary to look at, and just one more thing to worry about securing while offering nothing else new or unique.  And the IP addresses themselves are the *least* daunting thing about IPv6, IMO.

[kasperd]

but much less hard to burn through a /32.

Sure a large ISP handing out a /48 to each customer can consume a /32 in no time. But in this case we are talking about an ISP with a /20 worth of IPv4 addresses. They can hand out a /48 to each customer and still have plenty of IPv6 addresses left by the time that IPv4 space gets really tight.

Your example use of /57 and /58 prefix lengths got me thinking, though.

I didn't actually suggest using a /57 at any point. What I said was you could be using a /57 on average. Everything delegated to the customer would still be on a nibble boundary.

The RFC draft I mentioned explicitly states that CPE routers by default should round up its prefix request to a nibble boundary. I would expect most such routers to need between 2 and 7 /64s. And anything from 2 to 16 would be rounded up to a /60. Hence I expect that a year or two from now, most new routers will request a /60.

I did suggest the provider could be using a /58 per customer. That was in order to provision for a customer with more than one router requesting a /60. Even though from the customers point of view these are completely independent /60 and /64 prefixes, it makes sense for the ISP to keep them within a /58 to easier keep track of which addresses goes with which customer, and to keep routing tables small.

My main point was that a /58 was the longest prefix you should consider provisioning per customer. After learning the size of this ISP I wouldn't even suggest that they provision that long a prefix per customer, they will have plenty of addresses to provision a shorter prefix to each customer.

Assume an ISP have some equipment where they can terminate 50 customer connections (I don't know if that is a size they would actually use, this is just for the example). How large a prefix should they route to this equipment?

They could route a /52 to the equipment and allocate a /58 out of that for each customer. (You'd be wasting 14 /58 blocks, but that's not a problem). Then that equipment can split each /58 into 3 /60 blocks for delegation and plenty /64 for link to customer and more for delegation. In this case all routing is happening at nibble boundaries namely /52, /60, and /64. But to find out which customer an IP address belongs to, you'd be looking at /58s. The /58s is only relevant for administrative purposes within the ISP. It affects nobody outside of that ISP, and they can use any size they please.

In the same setup, if you prefer to change that /58 to a nibble boundary, then you'd have a /56 per customer. Out of that /56 you'd use one /64 for the link to the customer and you'd have 15 /60s and 15 /64s left, which could be delegated to the customer's routers. Then the equipment would need to have a /48 routed to it in order to have enough /56s for 50 customers. You'd be wasting 206 /56 blocks.

At this level of the hierarchy you'd only have an HD-ratio of 70%. Those 70% would be less than the 80% target which is what is required in order to be able to have a /48 to every end site. But since the example was splitting a single /48 into blocks to route to individual customers, then it isn't actually a problem. A /48 for every such piece of equipment would be perfectly acceptable, even if most of it is wasted. You'd still need to route more /48s to it, if any customer actually has a router requesting a /48.

If you would actually route a /40 to one such piece of equipment in order to provision a /48 for each of the 50 customers. Then your waste would reach a level where it is a slight concern. Again you'd have an HD-ratio of 70% in this byte of the address. If the previous byte of the address had same utilization, you'd only have 50 such pieces of equipment within the entire /32, and you could only allow for 2500 customers. That is not sufficient.

If you want to achieve 80% HD-ratio, you may need to subnet at boundaries that are not nibbles. But it is only for the subnetting within the ISP. They can receive a /32 from RIPE and delegate /48s to customers. But those 16 bits that the ISP has for subnetting may need to be split with finer granularity than nibble boundaries.

If you only ever subnet on nibble boundaries, then the worst case is an HD-ratio of 25% when you have a fanout of 2 and allocate an entire nibble. If you subnet on arbitrary bits, then the worst case is an HD-ratio of 77% when you have a fanout of 5 and allocate three bits. This is assuming subnets of similar sizes.

I was saying that until there's some really rock solid consensus about standard ways to deploy v6 and to make addressing and subnetting less frightening

IPv4 is much worse. With IPv4 you have to aim for a much higher HD-ratio. With IPv4 I think you might need to aim for 95% or higher HD-ratio. An HD-ratio of 90% is certainly not good enough with the shortage of IPv4 addresses. Needing such a high HD-ratio gives you very little flexibility.

With IPv6 you only need an HD-ratio of 80%. And if you don't need to allocate a /48 to each customer, but instead only hand them whatever prefix they request using DHCPv6, you can go with an even lower HD-ratio. That means you can organize your subnetting in a much cleaner way.

Within the ISP network do subnetting at boundaries that work for you. I have given quite a few examples in this thread. But they are nothing but examples. If I knew your network, I could give more appropriate suggestions for your specific network. And don't care what the rest of the world does. Within your own network you only need to care what works for you. And before you start deploying verify that you have allocated enough bits to the fanout you need at each level of the hierarchy, and verify that you have achieved a sufficiently high HD-ratio.

Between the ISP and the customers my advice is to allocate one /64 for the link to each customer and to delegate prefixes to each customer as requested by their routers through DHCPv6.

On the interface between the ISP and the customer I believe consensus is that prefix delegation will be done using DHCPv6. There may not be consensus about how large a prefix you should delegate to each customer. There is probably never going to be consensus, and it doesn't matter anyway. You can just choose a size and go with it or simply give each customer whatever their router asks for (up to some reasonable maximum).

[tdensmore]

Thanks for the very thorough reply.  I've actually already started rolling things out, and settled on:

/32:

/36 per POP, with extra /36s in reserve in case some POPs need more - some will obviously need less, but I'm not getting in to VLSM-per-pop
/48 for big customers
/56 for smaller customers (DSL, etc), sparsely allocated
/64 per P2P, applied as /126

I guess we'll see down the road if that was a bad plan.  I honestly considered just rolling with multiple /40s per POP since AFAICT that's going to be be shortest summary I'll be able to use anywhere anyhow.

Lots and lots of work to do still, but making progress every day.  I hope that at some point it's actually worth it.  Right now, our v6 customer base = 1.  Me.

Thanks again, and sorry to the OP for the complete thread-hijack.  Hopefully all this info was useful.

[kasperd]

I guess we'll see down the road if that was a bad plan.

Your plan sounds reasonable. I guess the /36s you have in reserve are more likely going to be used to increase the number of POPs than because you ran out of addresses in a POP.

How are you delegating addresses to customers? DHCPv6? Static configuration? Something different?

Thanks again, and sorry to the OP for the complete thread-hijack.  Hopefully all this info was useful.

It probably was useful. You are further ahead in deploying IPv6 than eyebv6 is.

[Ahmed M. H. Alzaeem]

thank u both  for this discussion

i  could pickup some info from ur dialogue .
;D ;D ;D

[tdensmore]

How are you delegating addresses to customers? DHCPv6? Static configuration? Something different?

Currently our customers = 1, me.  I'm using a statically configured tunnel since my CPE doesn't support IPv6.  To begin with, if I ever get a request, we'll use static assignment, but I hope to eventually figure out a way to deliver v6 dynamically which will allow me to track connections.  PPPoX and RADIUS is one option I've looked at, DHCP-PD is another.  I like the PD method, but at the same time I don't want to spend a lot of cycles "provisioning" customer DHCP IDs.

While I didn't quite this piece of your post, unless my math is off, a /36 allows for 4k /48s.  If we actually deliver /64 + sparse /56, I could eat that w/o much effort at all in some DSL POPs.

[kasperd]

Currently our customers = 1, me.  I'm using a statically configured tunnel since my CPE doesn't support IPv6.

That's a starting point. I think one of the next steps to take after that is decide on some CPE that actually supports IPv6. You should find equipment that you can recommend to your customers, ideally from two or three different vendors.

Acquiring four different models with IPv6 support and deciding which works best is something that you'll need to do at some point.

To begin with, if I ever get a request, we'll use static assignment

The first customers who ask will probably be happy with a static assignment. But an ISP of any significant size will have customers, who will never ask you for IPv6. But they will still expect to be able to reach IPv6 only content, so it will be your responsibility to get them IPv6 even though they didn't ask for it. And those customers will probably not be happy with a static assignment, as they perceive that as way too complicated.

but I hope to eventually figure out a way to deliver v6 dynamically which will allow me to track connections.  PPPoX and RADIUS is one option I've looked at, DHCP-PD is another.  I like the PD method, but at the same time I don't want to spend a lot of cycles "provisioning" customer DHCP IDs.

Any manual work that you can avoid having to do is going to simplify things. But if the choice is between you doing the manual work and your customer doing it, it may be better if you do it yourself, since you are more likely to get it right than the customer is.

Every customer who gets it wrong means you need to spend time figuring out what went wrong and fix it.

Large ISPs have a database listing the MAC address of each customer's CPE. Can't that be used for prefix delegation as well?

While I didn't quite this piece of your post, unless my math is off, a /36 allows for 4k /48s.  If we actually deliver /64 + sparse /56, I could eat that w/o much effort at all in some DSL POPs.

I don't know what point you are trying to make.

One /36 could for example allow for 2,048 /48s, 512,000 /56s and 3,145,728 /64s. Do you have any single POP with more than 2k large customers or more than 500k customers total?

OTOH assigning a /36 to each POP means you can have no more than 16 POPs total. I don't know how many POPs you have right now, but 16 POPs doesn't sound like a lot to me.

Either way I do think your allocation strategy sounds sensible. If you do use all 16 /36s and each POP has used more than 25% of the /48s, then you should be able to get more address space.

[tdensmore]

Large ISPs have a database listing the MAC address of each customer's CPE. Can't that be used for prefix delegation as well?

Maybe.  I've only played with cisco and mikrotik, and barely scratched the surface.  I'm not sure I'll get a MAC addy for T1 or DSL circuits.  That was really only meant as a comment, not that I wouldn't consider using the technology.  The big point was that it seems more complex than with IPv4, and that I have a whole lot of work to do in that area.  I'm a little worried about supplying IPv6 to customers who aren't aware of it, just in case their firewalls aren't able to handle v6 sensibly.

While I didn't quite this piece of your post, unless my math is off, a /36 allows for 4k /48s.  If we actually deliver /64 + sparse /56, I could eat that w/o much effort at all in some DSL POPs.

I don't know what point you are trying to make.

One /36 could for example allow for 2,048 /48s, 512,000 /56s and 3,145,728 /64s. Do you have any single POP with more than 2k large customers or more than 500k customers total?

OTOH assigning a /36 to each POP means you can have no more than 16 POPs total. I don't know how many POPs you have right now, but 16 POPs doesn't sound like a lot to me.

Either way I do think your allocation strategy sounds sensible. If you do use all 16 /36s and each POP has used more than 25% of the /48s, then you should be able to get more address space.

Sorry, that should have been "quote" not "quite."

Well, with the proposed sparse allocation of those /56s, I'd be reserving a /56 for each one assigned, essentially using the /48 model in case it turns out /56 is a terrible idea for whatever reason.  Mostly saying "/56 should be enough, but if not, we can backpedal to /48 effortlessly, and if so, we can back-fill with future customers."  How this is done technically when not statically assigning IPs remains to be seen, so this is essentially a vaporware plan and nothing else at this point.  Might be simple, might be impossible.

I currently have 4 POPs IPed with 2 more awaiting assignment, and 2 that I'm probably going to IP out of the ranges assigned to their parent POPs since they are small satellites that would probably never use a /40 let alone a /36.  Those 2 that are waiting are in limbo based on possible upcoming network architecture changes, and doing the same work twice for no reason strikes me as foolish.  In at least one of the IPed POPs if we were to assign /48s and sparse /56s we could probably come close to filling up a /36.  It was a gamble going with /36, but it seemed to make more sense than tons of /40s.  ARIN was apparently willing to allocate either a /28 or a /32, but we would have had to pay quite a bit more for the /28, so we went with the /32.

Thanks again for the good discussion!

[kasperd]

I'm a little worried about supplying IPv6 to customers who aren't aware of it, just in case their firewalls aren't able to handle v6 sensibly.

How large a fraction of customers are even aware that they are getting an IPv4 address from you?

The transition should happen with the majority of customers not even noticing that it is happening, so at some point you will need to provide IPv6 access to customers, who don't know what IPv4 or IPv6 is.

You might have good reasons to think that turning on IPv6 at this point introduces some security risk. Is leaving IPv6 disabled the only solution you can think of? I'd consider an approach with stateless filters in your routers, that the customer can get turned off at request. But I don't know if you have the hardware to do it.

Some ISPs have a website where customers can configure their connection? Do you already have such a site? Have you considered adding a page, where customers can choose between IPv4 only and dual stack (and some time in the future an IPv6 only option as well).

My guess is that if you had that option, some customers would actually go and enable dual stack as soon as the word starts spreading.

Well, with the proposed sparse allocation of those /56s, I'd be reserving a /56 for each one assigned, essentially using the /48 model in case it turns out /56 is a terrible idea for whatever reason.  Mostly saying "/56 should be enough, but if not, we can backpedal to /48 effortlessly, and if so, we can back-fill with future customers."

I see. That is a quite sensible approach. There is a way to generalize this strategy to a hierarchy, and it has some name, which I unfortunately don't remember.

People have also proposed doing this on individual links, where you reserve a /64 but assign only a /116 or a /126 out of that /64.

Might be simple, might be impossible.

It is possible. The question is, how much work is it, and did somebody do most of the work already?

I currently have 4 POPs IPed with 2 more awaiting assignment, and 2 that I'm probably going to IP out of the ranges assigned to their parent POPs since they are small satellites that would probably never use a /40 let alone a /36.

In that case I agree that you don't have to plan for more than 16 POPs yet.

Those 2 that are waiting are in limbo based on possible upcoming network architecture changes, and doing the same work twice for no reason strikes me as foolish.  In at least one of the IPed POPs if we were to assign /48s and sparse /56s we could probably come close to filling up a /36.

If you do keep a /48 reserved for each customer, then it is no surprise that you can fill out a /36 in one POP.

It was a gamble going with /36, but it seemed to make more sense than tons of /40s.

That's why sometimes it makes sense to split on boundaries that are not a multiple of 4 bits. IPv6 was designed with lots of addresses, but not enough to always round to multiples of 4 bits (which could in the worst case waste 75% of the bits).

What you can do is the exact same thing you are doing with the customer delegations. You can reserve a /36 per POP but only assign a /40 of that initially. Once a POP grows beyond the /40 you can make it a /39 (or two adjacent /40s, which is the same thing).

ARIN was apparently willing to allocate either a /28 or a /32, but we would have had to pay quite a bit more for the /28, so we went with the /32.

That's the problem. What is the right pricing model? They do need some money, and it makes sense that large ISPs pay more of that than small ISPs. And it also makes sense to take more money for the shorter prefix to keep people from requesting excessive amounts of address space.

But this model was not intended to mean that every ISP goes with a /32 and gives each customer a tiny subnet just so the ISP can save money. In the end that sort of model would mean that the big ISPs can save money by getting fewer addresses than they should, which just means that the price you need to pay for a /32 would have to go up enough to keep ARIN funded. Essentially that means small ISPs subsidizing large ISPs.

At least on RIR has gone with a model where you don't pay for both IPv4 and IPv6 addresses, you only pay the highest of the two prices. I don't recall exact numbers, but it might mean that for ever IPv4 address you pay for, you effectively get a /46 of IPv6 space for free.

In the future it may make sense that pricing takes into account how large prefixes the ISP hands out to customers, such that large ISPs cannot get savings by only handing each customer a /64. Such behaviour from the large ISPs would be bad for both their customers who get a poorer service as well as for other ISPs who gets to pay for the savings. An adaptation of such a model to make IPv4 prefixes cheaper for those ISPs who delegate IPv6 prefixes to their customers would be a welcome change.

[tdensmore]

I'm a little worried about supplying IPv6 to customers who aren't aware of it, just in case their firewalls aren't able to handle v6 sensibly.

How large a fraction of customers are even aware that they are getting an IPv4 address from you?

Probably not a large number, but most of them are behind modems that NAT, and those that aren't are usually behind routers that NAT.  I have no experience with IPv4 NAT routers that will "do" IPv6 so far, so I have to plead ignorance in this case.  I'm about as convinced that eui-64 = security as I am that NAT = security.  I mostly don't want a choice I make to expose my customers to attacks until I have a better grasp of how things will ultimately look.

I'd consider an approach with stateless filters in your routers, that the customer can get turned off at request. But I don't know if you have the hardware to do it.

Can you give me a better idea of what this means or where to begin reading up on it?  One of my concerns is "happy eyeballs" and the like would start to prefer v6, and for a huge number of users, google, youtube, and facebook = "The Internet."  I had thought of using something stateful to allow expected inbound traffic back in, but applying that to every interface might be a PITA.  I obviously haven't done much research in this area yet at all, but I have seen ip6tables in pre-2.6.30 kernels totally break IPv6 when conntrack isn't possible.

Some ISPs have a website where customers can configure their connection? Do you already have such a site? Have you considered adding a page, where customers can choose between IPv4 only and dual stack (and some time in the future an IPv6 only option as well).

My guess is that if you had that option, some customers would actually go and enable dual stack as soon as the word starts spreading.

Unfortunately, we don't have any sort of automated provisioning database at all.  More or less *everything* is done manually.  Maybe someday :-)

Well, with the proposed sparse allocation of those /56s, I'd be reserving a /56 for each one assigned, essentially using the /48 model in case it turns out /56 is a terrible idea for whatever reason.  Mostly saying "/56 should be enough, but if not, we can backpedal to /48 effortlessly, and if so, we can back-fill with future customers."

I see. That is a quite sensible approach. There is a way to generalize this strategy to a hierarchy, and it has some name, which I unfortunately don't remember.

People have also proposed doing this on individual links, where you reserve a /64 but assign only a /116 or a /126 out of that /64.

I've always just seen it referred to as "sparse allocation" - assign one, skip one.  I burn a /64 per P2P but only assign a /126 to P2P links, not for sparseness, but because I want to avoid ping-pong, etc, and I don't want to have to manage prefixes longer than /64 (other than hosts, obviously) in an IPAM.  So, it amounts to laziness, but I can pretend it's due to BCP.

It was a gamble going with /36, but it seemed to make more sense than tons of /40s.

That's why sometimes it makes sense to split on boundaries that are not a multiple of 4 bits. IPv6 was designed with lots of addresses, but not enough to always round to multiples of 4 bits (which could in the worst case waste 75% of the bits).

What you can do is the exact same thing you are doing with the customer delegations. You can reserve a /36 per POP but only assign a /40 of that initially. Once a POP grows beyond the /40 you can make it a /39 (or two adjacent /40s, which is the same thing).

Right.  I don't really have any way to apply an entire /36 per POP anyhow, so it's just theoretical hierarchy to make management easier - back to IPAM, laziness, and BCP.  How it'll really appear in the routing table is as a bunch of /40s.

ARIN was apparently willing to allocate either a /28 or a /32, but we would have had to pay quite a bit more for the /28, so we went with the /32.

That's the problem. What is the right pricing model? They do need some money, and it makes sense that large ISPs pay more of that than small ISPs. And it also makes sense to take more money for the shorter prefix to keep people from requesting excessive amounts of address space.

But this model was not intended to mean that every ISP goes with a /32 and gives each customer a tiny subnet just so the ISP can save money. In the end that sort of model would mean that the big ISPs can save money by getting fewer addresses than they should, which just means that the price you need to pay for a /32 would have to go up enough to keep ARIN funded. Essentially that means small ISPs subsidizing large ISPs.

At least on RIR has gone with a model where you don't pay for both IPv4 and IPv6 addresses, you only pay the highest of the two prices. I don't recall exact numbers, but it might mean that for ever IPv4 address you pay for, you effectively get a /46 of IPv6 space for free.

ARIN is one of those RIRs - a /32 didn't cost anything additional, but a /28 would have doubled our yearly fees, and would have been a total non-starter.  ARIN has an equiv IPv6 fee schedule listed for each IPv4 "size" but at the time we received our allocation, they were only assigning /28 or /32 in most cases.  There was some discussion on the ARIN mailing list about this being too restrictive in some cases, but I don't think it ever made it past the discussion phase.

[kasperd]

I'd consider an approach with stateless filters in your routers, that the customer can get turned off at request. But I don't know if you have the hardware to do it.

Can you give me a better idea of what this means or where to begin reading up on it?

In case of TCP, the completely stateless approach would be to reject SYN packets coming from outside, such that those packets do not reach your customer. All other TCP packets would be permitted in both directions.

In that setup if the user is running some vulnerable server on their computer, then it cannot be attacked because nobody can open a TCP connection when the SYN packet is never reaching the server.

Now all an attacker can do is to send non SYN packets to your customers. So an attacker would have to find a weakness that can be exploited by sending a TCP packet that doesn't even match an open connection. Such a weakness is much less likely than some vulnerable server accidentally left open.

I don't know what support existing products have in this respect. But I know how it should work in principle, and it is not very complicated.

In case of UDP a stateless filter would have to make some assumptions about how port numbers are used on the customer side. Obviously you shouldn't make assumptions about the port numbers on the attacker side. If vulnerable services are on port numbers between 1 and 49151 and ephemeral ports are between 49152 and 65535, then you can reject UDP packets to ports 1 through 49151 and permit packets to ports 49152 through 65535.

Unfortunately you cannot completely rely on software following recommendations on port usage, for example Linux by default uses 32768-61000 for ephemeral ports.

If you can afford stateful tracking for some traffic but not all, then you can do much better. But at that point things gets complicated.

One of my concerns is "happy eyeballs" and the like would start to prefer v6, and for a huge number of users, google, youtube, and facebook = "The Internet."  I had thought of using something stateful to allow expected inbound traffic back in, but applying that to every interface might be a PITA.  I obviously haven't done much research in this area yet at all, but I have seen ip6tables in pre-2.6.30 kernels totally break IPv6 when conntrack isn't possible.

I guess the hardware you'd want to do this on is routers that can forward packets in hardware, and AFAIK ip6tables isn't used on such hardware. But regardless of which platform is being used, it is obviously possible, that implementations are buggy. I know the principles, but I don't know about the exact set of features and bugs available in specific products.

I burn a /64 per P2P but only assign a /126 to P2P links, not for sparseness, but because I want to avoid ping-pong, etc

Is a /126 sufficient to prevent that? I would have thought you had to go to a /127 to not have any destination address, which could loop on a link. But I was also under the impression, that both ends of the connection are responsible for not forwarding a packet back on the link on which it arrived, so the problem you describe could only happen if both ends of the link are running a buggy stack.

So, it amounts to laziness

Some amount of laziness is expected when dealing with IPv6 allocations. The point with having so many bits in an IPv6 address is to reduce the amount of administration work you need to do. You can call it laziness, but you can also call it rationalization.

ARIN is one of those RIRs - a /32 didn't cost anything additional, but a /28 would have doubled our yearly fees, and would have been a total non-starter.

I don't know how large the payments are compared to the profits of an ISP. On one hand I think double yearly fees just to get started with IPv6 sounds excessive. On the other hand I would have thought that the fees were small enough that a doubling would be seen as a quite reasonable investment in the future.

ARIN has an equiv IPv6 fee schedule listed for each IPv4 "size" but at the time we received our allocation, they were only assigning /28 or /32 in most cases.

So there is an equivalent size that would be free, but you cannot get that size because you have to round down or round up? In that case rounding down to a size, which doesn't cost you any extra fees at the moment can very well sound like a reasonable business decision. By the time where you really feel a need to grow from a /32 to a /28, I think IPv6 has become important enough to warrant the extra fee a /28 will cost.