NAT66 and the subscriber prefix length
Not long ago, ARIN changed the IPv6 policy so that residential subscribers could be issued with a /56 instead of the normal /48 assignment. This was done so that ISPs with large numbers of subscriber sites would not exhaust their /32 (or larger) allocations too soon. Since these ISPs are allowed to assign a /56 to residential subscriber sites, their initial IPv6 allocation will last a lot longer and they won't have to apply for an additional allocation while everyone is getting up to speed with an IPv6 Internet. Now, however, the IETF is discussing a form of NAT for IPv6 called NAT66. See this draft for details <http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-01.txt> Part of this new NAT is that they are checksum neutral. They do this by modifying bits in the address that are not needed. Specifically, they assume that the end site has a /48 allocation, and that the next 16 bits up to the /64 boundary, are non-essential information outside the end-site boundary. These bits are then twiddled to preserve the IPv6 header checksum. Of course, these are the same bits that an ISP relies on for reducing the assignment size to /56. I see a potential conflict here. If we assume that NAT66 will be widely used by consumers, then it follows that consumer end-sites will need a /48 assignment in order for IPv6 to work. But some ISPs want to reduce the end site assignment to /56 meaning that NAT66 won't work for those consumers. Of course, it's not all set in stone yet which is why I am posting this to NANOG. If ISP's who intend to use /56 allocations could join in the discussions, then perhaps we could develop some form of NAT66 that works with /56 prefix lengths. Personally, I would be happy to just see every site consistently use a /48 assignment. Corporate campus or one-room studio apartment; it's all the same to me. --Michael Dillon
On Fri, 14 Nov 2008, michael.dillon@bt.com wrote:
Not long ago, ARIN changed the IPv6 policy so that residential subscribers could be issued with a /56 instead of the normal /48 assignment. This was done so that ISPs with large numbers of subscriber sites would not exhaust their /32 (or larger) allocations too soon. Since these ISPs are allowed to assign a /56 to residential subscriber sites, their initial IPv6 allocation will last a lot longer and they won't have to apply for an additional allocation while everyone is getting up to speed with an IPv6 Internet.
We returned our /32 for a /25 (with /22 being reserved) and current plan is to hand out /48s to everybody (unless they need even more space, then they'll have to apply). So, doing /56 to end users just because you happen to have a /32 right now sounds like a bad plan, it doesn't take that many hours to get a larger space if you can justify it (which wasn't that hard for us). We received our /32 (as a /35 I think) back in 2000 or so, policy has changed since then, with RIPE it's not that hard to get a much larger space with a long term growth plan. My hope is that we'll make do with this /22 space for at least 5-10 years (67 million customer /48s is quite a lot), unless something really big happens, and then we'll just have to get an even larger space. So message should be that /48 to end users is the way to go, and this should suit residential and SME market without any additional administrative overhead depending on customer size. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Fri, Nov 14, 2008 at 2:28 PM, Mikael Abrahamsson <swmike@swm.pp.se>wrote:
On Fri, 14 Nov 2008, michael.dillon@bt.com wrote:
Not long ago, ARIN changed the IPv6 policy so that
residential subscribers could be issued with a /56 instead of the normal /48 assignment. This was done so that ISPs with large numbers of subscriber sites would not exhaust their /32 (or larger) allocations too soon. Since these ISPs are allowed to assign a /56 to residential subscriber sites, their initial IPv6 allocation will last a lot longer and they won't have to apply for an additional allocation while everyone is getting up to speed with an IPv6 Internet.
We returned our /32 for a /25 (with /22 being reserved) and current plan is to hand out /48s to everybody (unless they need even more space, then they'll have to apply).
So, doing /56 to end users just because you happen to have a /32 right now sounds like a bad plan, it doesn't take that many hours to get a larger space if you can justify it (which wasn't that hard for us).
We received our /32 (as a /35 I think) back in 2000 or so, policy has changed since then, with RIPE it's not that hard to get a much larger space with a long term growth plan. My hope is that we'll make do with this /22 space for at least 5-10 years (67 million customer /48s is quite a lot), unless something really big happens, and then we'll just have to get an even larger space.
So message should be that /48 to end users is the way to go, and this should suit residential and SME market without any additional administrative overhead depending on customer size.
-- Mikael Abrahamsson email: swmike@swm.pp.se
This raises questions for me: we are a mixed enterprise/campus environment. Recently got a /45 assigned, so we have a /48 per site (it was some work to convince ARIN that fancy subnetting to make a /46 stretch a little further made no sense.) We have also started offering residential Internet to those living on campus, which has been very popular (no suprise.) If I'm expected to assign a /48 per residential user, I'm already out of address space. Should I be requesting a /32? Is it acceptable to carve the /32 up a little for IPv4 style multi-homing? I'd rather come to terms with this now before I do any meaningful deployment. Tim:>
On 11/18/2008 at 11:03 AM, "Tim Durack" <tdurack@gmail.com> wrote: On Fri, Nov 14, 2008 at 2:28 PM, Mikael Abrahamsson <swmike@swm.pp.se>wrote:
On Fri, 14 Nov 2008, michael.dillon@bt.com wrote:
Not long ago, ARIN changed the IPv6 policy so that
residential subscribers could be issued with a /56 instead of the normal /48 assignment. This was done so that ISPs with large numbers of subscriber sites would not exhaust their /32 (or larger) allocations too soon. Since these ISPs are allowed to assign a /56 to residential subscriber sites, their initial IPv6 allocation will last a lot longer and they won't have to apply for an additional allocation while everyone is getting up to speed with an IPv6 Internet.
We returned our /32 for a /25 (with /22 being reserved) and current plan is to hand out /48s to everybody (unless they need even more space, then they'll have to apply).
So, doing /56 to end users just because you happen to have a /32 right now sounds like a bad plan, it doesn't take that many hours to get a larger space if you can justify it (which wasn't that hard for us).
We received our /32 (as a /35 I think) back in 2000 or so, policy has changed since then, with RIPE it's not that hard to get a much larger space with a long term growth plan. My hope is that we'll make do with this /22 space for at least 5-10 years (67 million customer /48s is quite a lot), unless something really big happens, and then we'll just have to get an even larger space.
So message should be that /48 to end users is the way to go, and this should suit residential and SME market without any additional administrative overhead depending on customer size.
-- Mikael Abrahamsson email: swmike@swm.pp.se
This raises questions for me: we are a mixed enterprise/campus environment. Recently got a /45 assigned, so we have a /48 per site (it was some work to convince ARIN that fancy subnetting to make a /46 stretch a little further made no sense.)
A /45? I thought all allocations were on nibble borders for IP6.ARPA considerations.
On Tue, Nov 18, 2008 at 2:33 PM, Crist Clark <Crist.Clark@globalstar.com>wrote:
On 11/18/2008 at 11:03 AM, "Tim Durack" <tdurack@gmail.com> wrote: On Fri, Nov 14, 2008 at 2:28 PM, Mikael Abrahamsson <swmike@swm.pp.se wrote:
On Fri, 14 Nov 2008, michael.dillon@bt.com wrote:
Not long ago, ARIN changed the IPv6 policy so that
residential subscribers could be issued with a /56 instead of the normal /48 assignment. This was done so that ISPs with large numbers of subscriber sites would not exhaust their /32 (or larger) allocations too soon. Since these ISPs are allowed to assign a /56 to residential subscriber sites, their initial IPv6 allocation will last a lot longer and they won't have to apply for an additional allocation while everyone is getting up to speed with an IPv6 Internet.
We returned our /32 for a /25 (with /22 being reserved) and current plan is to hand out /48s to everybody (unless they need even more space, then they'll have to apply).
So, doing /56 to end users just because you happen to have a /32 right now sounds like a bad plan, it doesn't take that many hours to get a larger space if you can justify it (which wasn't that hard for us).
We received our /32 (as a /35 I think) back in 2000 or so, policy has changed since then, with RIPE it's not that hard to get a much larger space with a long term growth plan. My hope is that we'll make do with this /22 space for at least 5-10 years (67 million customer /48s is quite a lot), unless something really big happens, and then we'll just have to get an even larger space.
So message should be that /48 to end users is the way to go, and this should suit residential and SME market without any additional administrative overhead depending on customer size.
-- Mikael Abrahamsson email: swmike@swm.pp.se
This raises questions for me: we are a mixed enterprise/campus environment. Recently got a /45 assigned, so we have a /48 per site (it was some work to convince ARIN that fancy subnetting to make a /46 stretch a little further made no sense.)
A /45? I thought all allocations were on nibble borders for IP6.ARPA considerations.
2620:0000:/23 is PI. ARIN makes assignments to end user sites of anywhere between /48 and /40, depending on your justification. ARIN wanted to give us a /46 for 5 sites, which made no sense. We pushed back for a /45, and that's what they gave us. Still not convinced it's going to be enough. Tim:>
We have also started offering residential Internet to those living on campus, which has been very popular (no suprise.)
You've started your own ISP. ISP's get a /32 from ARIN. Case closed. In fact, you are better off treating your non-ISP networks as a customer of your ISP and assigning a /48 to each of your non-ISP sites. This is an area where IPv4 and IPv6 differ. --Michael Dillon
michael.dillon@bt.com wrote:
We have also started offering residential Internet to those living on campus, which has been very popular (no suprise.)
You've started your own ISP. ISP's get a /32 from ARIN. Case closed.
In fact, you are better off treating your non-ISP networks as a customer of your ISP and assigning a /48 to each of your non-ISP sites. This is an area where IPv4 and IPv6 differ.
Too bad in Europe RIPE wants 3000EUR per month membership fees to give you PI IPv6 if you're an end user.
On 2008-11-19, at 09:25, Eugeniu Patrascu wrote:
michael.dillon@bt.com wrote:
We have also started offering residential Internet to those living on campus, which has been very popular (no suprise.) You've started your own ISP. ISP's get a /32 from ARIN. Case closed. In fact, you are better off treating your non-ISP networks as a customer of your ISP and assigning a /48 to each of your non-ISP sites. This is an area where IPv4 and IPv6 differ.
Too bad in Europe RIPE wants 3000EUR per month membership fees to give you PI IPv6 if you're an end user.
But surely he's not an end-user. He's an ISP, which means he's (potentially) an LIR. Joe
Joe Abley wrote:
But surely he's not an end-user. He's an ISP, which means he's (potentially) an LIR.
My gripe was that I wanted to get an IPv6 allocation from RIPE to start testing how IPv6 would fit in the company that I work for and build a dual stack network so that when the time comes, just switch on IPv6 BGP neighbors and update the DNS. But at almost 10.000 EUR per year it's an experiment I can't afford.
On 19 nov 2008, at 9:27, Eugeniu Patrascu wrote:
My gripe was that I wanted to get an IPv6 allocation from RIPE to start testing how IPv6 would fit in the company that I work for and build a dual stack network so that when the time comes, just switch on IPv6 BGP neighbors and update the DNS.
But at almost 10.000 EUR per year it's an experiment I can't afford.
You don't need PI for most things. You certainly don't need it to experiment.
My gripe was that I wanted to get an IPv6 allocation from RIPE to start testing how IPv6 would fit in the company that I work for and build a dual stack network so that when the time comes, just switch on IPv6 BGP neighbors and update the DNS.
But at almost 10.000 EUR per year it's an experiment I can't afford.
That is not an experiment. An experiment is where you go to <https://www.sixxs.net/tools/grh/ula/>, generate your own unique RFC 4193 prefix, and then implement your IPv6 network using that. When you are ready to switch on BGP peering with the rest of the world, get a /32 from your RIR, and renumber the network leaving the interface IDs the same. If you are concerned that renumbering will be hard, go back and generate another ULA, and renumber your network as part of your experiment. --Michael Dillon
michael.dillon@bt.com wrote:
My gripe was that I wanted to get an IPv6 allocation from RIPE to start testing how IPv6 would fit in the company that I work for and build a dual stack network so that when the time comes, just switch on IPv6 BGP neighbors and update the DNS.
But at almost 10.000 EUR per year it's an experiment I can't afford.
That is not an experiment.
I was hoping to do it in one step with my own IPv6 PI space and do the allocation and routing on the servers/routers/firewalls, see how that goes and when the time was right, just announce my prefix to the world :)
An experiment is where you go to <https://www.sixxs.net/tools/grh/ula/>, generate your own unique RFC 4193 prefix, and then implement your IPv6 network using that. When you are ready to switch on BGP peering with the rest of the world, get a /32 from your RIR, and renumber the network leaving the interface IDs the same.
Thanks for the URL, I was not aware of it. I guess I'll have to experiment with prefixes from that and see hot it goes.
If you are concerned that renumbering will be hard, go back and generate another ULA, and renumber your network as part of your experiment.
I'll probably do that also. Thanks.
On 19/11/2008 4:27, "Eugeniu Patrascu" <eugen@imacandi.net> wrote: [...]
My gripe was that I wanted to get an IPv6 allocation from RIPE to start testing how IPv6 would fit in the company that I work for and build a dual stack network so that when the time comes, just switch on IPv6 BGP neighbors and update the DNS.
But at almost 10.000 EUR per year it's an experiment I can't afford.
Where did the 10k come from? According the the 2009 billing scheme (http://www.ripe.net/ripe/docs/ripe-437.html) the highest annual fee is €5,500. The FAQ makes it clear that new members are automatically assigned to the Extra Small billing category (http://www.ripe.net/info/faq/membership/newlir-billing.html#2), putting membership and the sign-up fee at €3,300. I don't remember the RIPE NCC trying to sell expensive extras like a car dealership. I'd be surprised if the prices quoted aren't the prices that everyone pays. Regards, Leo
Before we get too deeply exercised, let Margaret and I huddle on it. The issue you raised can be trivially solved by adding the checksum offset to a different 16 bits in the address, such as bits 96..127. In fact, the only reason to care which bits it is added to is to handle multi-DMZ sites - multihoming. I'm looking at GSE/NAT66, which may be a very interesting application of the technology... On Nov 14, 2008, at 9:07 AM, <michael.dillon@bt.com> <michael.dillon@bt.com
wrote:
Not long ago, ARIN changed the IPv6 policy so that residential subscribers could be issued with a /56 instead of the normal /48 assignment. This was done so that ISPs with large numbers of subscriber sites would not exhaust their /32 (or larger) allocations too soon. Since these ISPs are allowed to assign a /56 to residential subscriber sites, their initial IPv6 allocation will last a lot longer and they won't have to apply for an additional allocation while everyone is getting up to speed with an IPv6 Internet.
Now, however, the IETF is discussing a form of NAT for IPv6 called NAT66. See this draft for details <http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-01.txt> Part of this new NAT is that they are checksum neutral. They do this by modifying bits in the address that are not needed. Specifically, they assume that the end site has a /48 allocation, and that the next 16 bits up to the /64 boundary, are non-essential information outside the end-site boundary. These bits are then twiddled to preserve the IPv6 header checksum. Of course, these are the same bits that an ISP relies on for reducing the assignment size to /56.
I see a potential conflict here. If we assume that NAT66 will be widely used by consumers, then it follows that consumer end-sites will need a /48 assignment in order for IPv6 to work. But some ISPs want to reduce the end site assignment to /56 meaning that NAT66 won't work for those consumers.
Of course, it's not all set in stone yet which is why I am posting this to NANOG. If ISP's who intend to use /56 allocations could join in the discussions, then perhaps we could develop some form of NAT66 that works with /56 prefix lengths.
Personally, I would be happy to just see every site consistently use a /48 assignment. Corporate campus or one-room studio apartment; it's all the same to me.
--Michael Dillon
On 14 nov 2008, at 14:55, Fred Baker wrote:
Before we get too deeply exercised, let Margaret and I huddle on it. The issue you raised can be trivially solved by adding the checksum offset to a different 16 bits in the address, such as bits 96..127.
Being checksum-equivalent is important so all protocols that use the standard checksum keep working without the NAT66 specifically supporting those protocols. The trouble is that in one's complement math 0xFFFF is equivalent to 0x0000 which means that there is loss of information, so accommodating the difference in the lower bits means some nasty corner cases are possible, while if it's in the subnet bits you just lose one subnet.
participants (9)
-
Crist Clark -
Eugeniu Patrascu -
Fred Baker -
Iljitsch van Beijnum -
Joe Abley -
Leo Vegoda -
michael.dillon＠bt.com -
Mikael Abrahamsson -
Tim Durack