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
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.
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...
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:>
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
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.
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
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.
[...]
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
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.