Let's face it - the current v6 assignment rules are to solve a 1990s set
of problems. A /64 isn't needed now that we have DHCP(v6).
It's needed to prevent people from NATing in v6, as they'll still want
their stuff behind a firewall, and some of them will want subnets.
Setting the idea in people's heads that a /64 IS going to be their own
statically is insane and will blow out provider's own routing tables
more than is rational.
No larger than their ARP tables are now.
Anthony Roberts wrote:
Let's face it - the current v6 assignment rules are to solve a 1990s set of problems. A /64 isn't needed now that we have DHCP(v6).
It's needed to prevent people from NATing in v6, as they'll still want
their stuff behind a firewall, and some of them will want subnets.
Why do we want to prevent people using NAT? If people choose to use NAT, then I have no issue with that.
This anti-NAT zealotism is tiring and misplaced.
Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational.
No larger than their ARP tables are now.
And ARP tables are propogated around networks? No, they're local to a router.
MMC
I don't think there's any need for the ISP's routers to advertise all the
prefixes they delegate. They'll advertise the /48 or whatever it is, and
then delegate chunks out of that.
Anthony Roberts wrote:
I don't think there's any need for the ISP's routers to advertise all the
prefixes they delegate. They'll advertise the /48 or whatever it is, and
then delegate chunks out of that.
My apologies for not being clear:
As I posted just before in reply to MarkA - I'm hoping that for the MAJORITY of customers that I can use PD and dynamic /64s (or whatever) local to a BRAS.
My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that.
I'm still not convinced though that, given DHCPv6 is going to be a reality for DNS assignment etc, that stateless autoconfig is needed and thus /64 doesn't have to be the smallest we assign.
MMC
Matthew Moyle-Croft wrote:
Anthony Roberts wrote:
I don't think there's any need for the ISP's routers to advertise all the
prefixes they delegate. They'll advertise the /48 or whatever it is, and
then delegate chunks out of that.
My apologies for not being clear:
As I posted just before in reply to MarkA - I'm hoping that for the
MAJORITY of customers that I can use PD and dynamic /64s (or whatever)
local to a BRAS.
My FEAR is that people ("customers") are going to start assuming that v6
means their own static allocation (quite a number are assuming this).
This means that I have a problem with routing table size etc if I have
to implement that.
Well, it is static, but like most static IP services offerd by an ISP,
if you leave you can't take your addresses with you. Even with DSL from
AT&T if you move locations you get a different subnet.
~Seth
I guess I was thinking about v4 modems which do not get a subnet, just an
IP address. If we really are handing out a /64 to each DSL & Cable modem,
then we may very well be recreating the same problem.
v4 just gets a single IP address, which is why we need NAT, and apparently
NAT is evil.
To some extent the /64 can be though of as "just an IP" from the ISP
perspective (in the same sense that an IPv4 IP is just a /32 "network"),
which has the ability for the CPE to then somehow split it out between
multiple hosts - probably using autoconfig (in the same way with IPv4 it's
"split up" by the port with NAT).
What happens when a customer wants to run multiple networks is something I
haven't seen answered yet - with NAT it's easy, but as I said, NAT is
apparently evil...
but my point was that people are starting to assume that v6 WILL mean
static allocations for all customers.
By design IPv6 should mean _less_ static allocations than IPv4 - in the
event that a client disconnects/reconnects and gets a new /64 then their
network *should* automatically handle that fact, with all clients
automagically renumbering themselves to the new /64, updating DNS, etc.
Local communications won't be impacted as they should be using the
link-local address.
The bit that isn't clear at the moment is if (and how well) that will
actually work in practice. And that brings us back to the good old catch-22
of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE
not supporting it because ISP don't...
Scott.
Anthony Roberts wrote:
I don't think there's any need for the ISP's routers to advertise all the
prefixes they delegate. They'll advertise the /48 or whatever it is, and
then delegate chunks out of that.My apologies for not being clear:
As I posted just before in reply to MarkA - I'm hoping that for the MAJORITY of customers that I can use PD and dynamic /64s (or whatever) local to a BRAS.
My FEAR is that people ("customers") are going to start assuming that v6 means their own static allocation (quite a number are assuming this). This means that I have a problem with routing table size etc if I have to implement that.
In my opinion, if they want static, they get business grade services, and get a /48. Or maybe a /56 over DSL perhaps.
And they pay more for it.
Otherwise they get PD like everybody else. The ability is there *now* for you to manage this expectation and say to customers that they are dynamic. Exploit it.
I'm still not convinced though that, given DHCPv6 is going to be a reality for DNS assignment etc, that stateless autoconfig is needed and thus /64 doesn't have to be the smallest we assign.
Dynamic PD requires SLAAC, unless your customers have say 30s DHCPv6 lease times on their DHCPv6 servers.
DSL reconnects, gets new IPv6 prefix, sends RA messages internally, hosts renumber and mark the existing prefix as deprecated until it expires.
The alternative is waiting for hosts to do a DHCPv6 query to get a new address. That is sub-optimal.
Seth Mattinen wrote:
Well, it is static, but like most static IP services offerd by an ISP,
if you leave you can't take your addresses with you. Even with DSL from
AT&T if you move locations you get a different subnet.
The issue is multiple POPs in a geographic region where customers could connect to either- if you have those and want them to work in adversity then you've got a problem as you need to allow the static addresses to propogate around. When that number is small then it's not a problem, but when you've got it large scale then you have a routing problem. This is my fear.
MMC
No, we should hand each home a /56 (or perhaps a /48, for the purists out
there) - allowing for multiple segments (aka subnet, aka links, etc.). Note
- the actual number of hosts is irrelevant; the 64 bits on the host side of
the address are not meant to encourage 18BB hosts/segment.
Oh, and utilization should be based on /56s anyway.
/TJ
Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.)
Actually, no - not poorly designed. The spec says it must be a /64 (excluding those starting with 000 binary) so that is what devices (rightfully) expect. Ref: RFC 4291 - IP Version 6 Addressing Architecture
/TJ
Scott Howard wrote:
but my point was that people are starting to assume that v6 WILL mean
static allocations for all customers.
By design IPv6 should mean _less_ static allocations than IPv4 - in the
event that a client disconnects/reconnects and gets a new /64 then their
network *should* automatically handle that fact, with all clients
automagically renumbering themselves to the new /64, updating DNS, etc.
Local communications won't be impacted as they should be using the
link-local address.
_should_
As I asked before - I'm really keen to actually do this stuff - but all I get is people who haven't done it telling me theory and not how it works in practise in a real ISP of some scale.
Telling customers "well, you might get renumbered randomly" isn't going to work, no matter what the theory about it all is. They do crazy and unexpected things and bleat about it even if you told them not to. At worse they stop paying you and leave!
My hope is that PD will be used for the majority and statics will be small in number. My FEAR is that customers have already been conditioned that v6 will mean statics for everyone because v6 has so many! (This has already been the assumption many have made from the customer side).
The bit that isn't clear at the moment is if (and how well) that will
actually work in practice. And that brings us back to the good old catch-22
of ISPs not supporting IPv6 because consumer CPE doesn't support it, and CPE
not supporting it because ISP don't...
Tell me about it.
As I asked before - has ANYONE done this before? ie. fully dualstacked to customers? Or is it still theory?
MMC
You give them more than a /64.
RFC4291 says that it should be a /48, but people seem to be keen on /56s now. /60s are even ok.
They key here is that is is divisible by 4, which leaves full hex digits for the customer to twiddle. Somewhere (free.fr?) are doing /61, which is a bit tough for people that aren't so technical.
Here in NZ, users typically purchase their own ADSL CPE, and that runs PPPoATM over ADSL, and does IPv4 NAT and so on. What is also common, is people buy a "wireless router" and plug it in to the back of their ADSL router. They now have two layers of NAT between wireless hosts and the Internet.
I looked at a packet trace of outgoing packets from an ISP - 17% of outgoing packets were from behind double NAT like this (TTL was 62 or 126, as opposed to 63 or 127).
For this topology to work in IPv6, multiple levels of PD are required, or users can no longer do this sort of plug-and-pray networking. Fun fun.
Personally, I think we should have PD forwarding - ie. a router can forward PD requests from routers behind it up to the ISP, and the ISP can dish out another /64. It means there are more routes in that particular router at the ISP, but it means you don't have to worry about how much address space to give to each customer - if they need more they ask for it automatically.
Let's face it - the current v6 assignment rules are to solve a 1990s set
of problems.
Perhaps, time moves ever forward.
A /64 isn't needed now that we have DHCP(v6). Setting
the idea in people's heads that a /64 IS going to be their own statically
is
insane and will blow out provider's own routing tables more than is
rational. (Think of the processing overhead of all the DSL/Cable customers
going up and down). This is going to be far more of an issue and drive
network design than a minor blow out in the v6 routing table.
However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable.
Also - does DHCPv6 currently have an option for prefix length? Just asking.
WRT /64s (or really, /56s and /48s being assigned to clients) - note that
these are NOT static assignments permanently belonging to the client. They
are hopefully dynamic, hopefully via DHCPv6-PD (hopefully
available/supported by then) ... similar to the single public IPv4 address
most of us dynamically get @home today.
AND, how does having a route for a /56 impact my routing table more than
having a route for a /xx (something longer)??
It does mean the ISP needs a larger initial allocation, but still just one
route ...
/TJ
TJ wrote:
Some devices will refuse to work if you subnet smaller than a /64. (Yes, poorly designed, etc.)
Actually, no - not poorly designed. The spec says it must be a /64 (excluding those starting with 000 binary) so that is what devices (rightfully) expect. Ref: RFC 4291 - IP Version 6 Addressing Architecture
I was just trying to head off the flood of "poorly designed" comments
last time I said such a thing on a different list. 
I find /64 convenient because it ends on a nice boundary out of my /48
and for my purposes it's more than enough space. The only annoyance I've
come across was my Cisco devices will only accept an EUI-64 address as a
host address in an ACL. Not a big deal though.
~Seth
My FEAR is that people ("customers") are going to start assuming that v6
means their own static allocation (quite a number are assuming this).
This means that I have a problem with routing table size etc if I have to
implement that.
Then work with them to break them of this dis-illusion.
I'm still not convinced though that, given DHCPv6 is going to be a reality
for DNS assignment etc, that stateless autoconfig is needed and thus /64
doesn't have to be the smallest we assign.
Yes and no. You sound like you are of the belief that SLAAC is bad / deficient - while it may not be perfect, some are big fans of its ease of use ATLEAST in certain deployment models.
TJ wrote:
No, we should hand each home a /56 (or perhaps a /48, for the purists out
there) - allowing for multiple segments (aka subnet, aka links, etc.).
If there are, say, 250-500 million broadband services in the world (probably more) then, if every ISP followed best practise for IPv6 address allocation, (sparse, bits for infrastructure, whatever etc) then what percentage of the space do we have left if we hand out /56 or /48s?). Taking into account the space already carved off for link local, private addressing, US Military etc.
Has anyone done some analysis of what this might look like? Especially with growth etc.
MMC
In a message written on Thu, Feb 05, 2009 at 11:58:33AM +1030, Matthew Moyle-Croft wrote:
My FEAR is that people ("customers") are going to start assuming that v6
means their own static allocation (quite a number are assuming this).
This means that I have a problem with routing table size etc if I have
to implement that.
Customers don't want static addresses.
They want DNS that works, with their own domain names, forward and
reverse.
They want renumbering events to be infrequent, and announced in
advance.
They want the box the cable/dsl/fios provider to actually work,
that is be able to do really simple stuff without having to buy
another stupid box to put behind it.
None of these require static, and in fact I'd think it would be
easier to get it right than it would be to do statics for most
providers. But, I must be wrong, since the only solution virtually
every provider offers is to "move up" to "a static IP".
TJ wrote:
However, many do not "have" DHCPv6 ... WinXP, MacOS, etc. are not capable.
Also - does DHCPv6 currently have an option for prefix length? Just asking.
I'm under no allusion that a /64 is going to be optional - it's really too late which is sad. I think people have just latched onto it and now accept it and defend it without thinking about "is this still the answer?". Just because it's in an RFC doesn't mean it's still the right answer in a changing world.
WRT /64s (or really, /56s and /48s being assigned to clients) - note that
these are NOT static assignments permanently belonging to the client. They
are hopefully dynamic, hopefully via DHCPv6-PD (hopefully
available/supported by then) ... similar to the single public IPv4 address
most of us dynamically get @home today.
Yep - that's what I'm hoping (as I've said and clarified). But I think the reality is that in the provider world, no matter what people here say, customer demand for an unchanging IPv6 range will increase not decrease - driving up provider routing size and complexity.
Has anyone done some analysis of what this might look like? Especially
with growth etc.
Sure, probably lots of people lots of times.
Off the top of my head, using some current/common allocations sizes:
Current "Global Unicast" space --> 2000::/3
An "average" RIR --> /12
an "average" ISP --> /32
an average enterprise --> /48
an average home user --> /56
So, "the current IPv6 world" (2000::/3) can support 512 standard RIR sized
allocations.
Each standard RIR can support 1M standard ISPs.
Each standard ISP can support 64K enterprises or 16M standard home-users, or
some combination thereof.
So - How much do we want held in reserve?
How "flexibly" (ref RFC3531) are we allocating our addresses?
How many total (enterprise | home) clients do we want to support?
Off the cuff, let's say we use left-most (sparse) allocation and only hit
50% efficiency (keeping the right-most bit totally in reserve!) ... If I am
an ISP, and I have 300M home users (/56s) I just need a /26, and that
actually gives me a lot of room for more clients (like 200M more). So -
what was the problem again?
Let's make it even more interesting - let's say I am an ISP, I am allocating
/48s, and I need to support - say - 6B assignments for every person in the
world + 2B for every organization in the world (#s chosen arbitrarily, feel
free to add another bit if it makes you feel better). Bearing in mind that
this means every single person and organization has 64k subnets, each of
which contains "as many hosts as is appropriate", and all of these are
globally routable ... I "just" need a /15 to cover this absolute worst case.
Heck, let's make it /14 for good measure. So now each standard RIR can
"only" support 4 of this size service provider, but we still have 512 RIR
sized allocations. If the individuals got /56s instead these numbers
getting even bigger ... So - what was the problem again?
Oh, and this is just from the 2000::/3 range ... next up, 4000::/3 ...
6000::/3, 8000::/3, a000::/3, c000::/3.
And if we feel like we burned through 2000::/3 too fast at some point in the
future, maybe we revisit the rules around the time we start thinking about
allocating from 4000::/3? (Or "skip one", and star the new rules with
6000::/3 ... I am not picky).
Note, I am _NOT_ saying we should be careless or cavalier about address
allocation, just saying we don't live in a constrained situation.
And if there is a choice to be made between
scalability/flexibility/summarization'ability (is that a word?) and strict
efficiency ... the efficiency loses.
/TJ
PS - Yes, 4.3B seemed really big at one point ... but seriously, do the
above numbers not _really_ sound big enough?
My addressing plan works like this:
ISP gets /32, 2001:db8::/32
- 2001:db8:0::/48 = ISP use
-- 2001:db8:0:0::/64 = infrastructure
--- 2001:db8:0:0:0:0:0::/112 = loopbacks ( 65536 )
--- 2001:db8:0:0:1:0:0::/112 through 2001:db8::ffff:ffff:ffff:0/112 = /112 link nets between ISP routers ( 281474976710656 )
-- 2001:db8:0::/64 through 2001:db8:0:ffff::/64 = ISP networks, ie. servers, etc.
- 2001:db8:1::/64 through 2001:db8:ffff:ffff::/64 = customer networks.
Assuming the above, we have 65535 /48s available to customers, or 16,711,680 /56s.
The "ISP use" /48 burns 256 /56s, or potential customers. So, like burning a /24 for the entire ISP operation.
So, if you have more than 65K business customers, get more than a /32.
If you have more than 16M residential or small business customers, get more than /32.
The above plan puts the addresses you type lots (loopbacks, link nets) on the shortest addresses you have - you can use the zero compression :: thing. These are also the addresses that cause the most trouble if fat fingered, so shorter addresses leave less room for error.
In addition, the entire first /64 (loopbacks, link nets) should never really receive packets from outside the network. Drop in an ACL.
Modification to the above plan is to use /64s for link nets between ISP routers, if you are worried about compatibility issues. You now have a trade off between 65k ISP server networks, and 65k link nets. Let's say 32k for each.