Assigning IPv6 /48's to CPE's?

Mailman List Mirror (Read Only)
21

Is it even a possibility then? A /48 to everyone means 48
bits left over for the network portion of the address.

That's 281,474,976,710,656 /48 customer networks. It's 16
million times the number of class C's in the current IPv4
Internet. Am I just not thinking large or long term enough?

No, you are just counting wrong. When you are talking /48's
you are talking "number of bits of of subnet hierarchy", not
"pile of pebbles on the beach". If you read the ARIN IPv6 policy
you will see that they don't count /48's like pebbles, instead
they use something called the HD Ratio.

Basically, this recognizes that IP networks are not flat piles
of pebbles, but have a hierarchical aggregation structure in
them. At each level of aggregation, you have to do a fitting
exercise, where you fit what you have into a power of two
sized block. If you have 5 subnets that need to be aggregated
into a single higher level subnet, then you must use 3 bits
of your subnet hierarchy, even though those 3 bits could be
used for as many as 8 subnets.

This is not waste. It is a fact imposed by the structure of
IPv6 (and IPv4) subnet addresses. In fact, when you "throw away"
subnets (addresses) like that, you are actually following a
prudent conservation policy. That's because this kind of bitwise
network addressing is cheaper to implement in hardware and
can be processed faster in hardware when doing things like
FIB lookups. That conserves MONEY and TIME which are vastly
more important to conserve than theoretical counting capacity
of a bitstring.

Remember, IP addresses don't really exist. They are just bitstrings
which some people like to arrange in orderly sets such as:

111000
111001
111010
111011
111100
111101
111110
111111

which is equivalent to 111000/3 or (111000,000111)

--Michael Dillon

22

> I'd rather push for /48 and have people settle on /56 than push for
> /56 and have people settle on /64.

Again, why the hang-up on 8 bit boundaries?

Look, why are we arguing about this? Why not split
the difference? If /48 is too big and /64 is too small,
let's go halfway and use /56, OK?

This has the advantage that it is on a 4 bit nibble
boundary which makes it the boundary between network
and interface much clearer in writing
2001:3ff3:effe:1200::0/56
If you wrote 2001:3ff3:effe:12a0::0/56 then I would
immediately see that there are too many bits in the network
portion. It also avoids a messy situation with reverse
DNS delegations.

In the end, the decision had to be made to but the boundary
somewhere, and with 16 bits to be divided plus the need to
use 4-bit boundaries, the choices were (4,12), (8,8), and
(12,4). Split the difference was the least objectionable.

ARIN's decision on this boundary point has since been accepted
by two other RIRs, so it seems to be community consensus now.

--Michael Dillon

23

>* /32 for ISPs unless they can justify more
>* /48 for subscribers unless they can justify more

Take someone like Comcast with ~12 million subscribers.

It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net
efficiency of 10% they are going to need to be allocated 120 million /48's.
It would take a /21 to give them 2^(48-21) = ~134 million /48's.

And indeed Rick, British Telecom, France Telecom and Deutsche Telekom
did exactly these calculations and used them to justify the /19's and
/20s that they were allocated from RIPE. Fortunately, there are only a
handful of Comcasts. The vast majority of ISPs have customer counts
well shy of the million mark.

If you have more than 65,000 customers today, you should have little
trouble justifying an initial IPv6 allocation larger than /32. You
simply state in your application that you intended to assign a /48 to
each. Any such reallocation up to a /48 is deemed to be automatically
justified at the registry level.

So in short, a /48 to subscribers seems like complete overkill, and a /32 to
ISP's seems completely inadequate (80 vs 16 bits).

This is why some folks recommend a /56 for small subscribers instead
of a /48, reducing the waste by two and a half orders of magnitude. In
a world where only the largest subscribers choose to deploy more than
4 IPv4 subnets (including their NATed subnets) why should the initial
IPv6 assignment exceed 256 subnets?

It seems to me while being extra super sure we meet goal 1 of making sure
NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of
prefixes to ISP's that are too small.

In my ever so humble opinion, IPv6 will not reach significant
penetration at the customer level until NAT has been thoroughly
implemented. Corporate information security officers will insist.
Here's the thing: a stateful non-NAT firewall is automatically less
secure than a stateful translating firewall. Why? Because a mistake
configuring a NAT firewall breaks the network causing everything to
stop working while a mistake with a firewall that does no translation
causes data to flow unfiltered. Humans being humans, mistakes will be
made. The first failure mode is highly preferable.

This is one of the trifecta that most seriously obstruct the
deployment and acceptance of IPv6. The others are: client stack
prefers IPv6 to IPv4 when available (so wonderful for Internet
stability during the deployment years) and "incompatibility" meaning
that instead of simply requiring a software upgrade after which the
IPv6 addresses corresponding to your configured IPv4 addresses just
work, IPv6 requires an entirely new set of allocations and an entirely
new configuration management infrastructure. Double the work. Somewhat
less than double the fun.

But that's just my opinion.

Regards,
Bill Herrin

24

That's 281,474,976,710,656 /48 customer networks. It's 16
million times the number of class C's in the current IPv4
Internet. Am I just not thinking large or long term enough?

No, you are just counting wrong. When you are talking /48's
you are talking "number of bits of of subnet hierarchy", not
"pile of pebbles on the beach". If you read the ARIN IPv6 policy
you will see that they don't count /48's like pebbles, instead
they use something called the HD Ratio.

I'm fully aware of HD ratio thanks :slight_smile:

My point was to give a rough approximation of the size difference here, not to talk about the specific numbers.

Basically, this recognizes that IP networks are not flat piles
of pebbles, but have a hierarchical aggregation structure in
them. At each level of aggregation, you have to do a fitting
exercise, where you fit what you have into a power of two
sized block. If you have 5 subnets that need to be aggregated
into a single higher level subnet, then you must use 3 bits
of your subnet hierarchy, even though those 3 bits could be
used for as many as 8 subnets.

This is not waste. It is a fact imposed by the structure of
IPv6 (and IPv4) subnet addresses. In fact, when you "throw away"
subnets (addresses) like that, you are actually following a
prudent conservation policy. That's because this kind of bitwise
network addressing is cheaper to implement in hardware and
can be processed faster in hardware when doing things like
FIB lookups. That conserves MONEY and TIME which are vastly
more important to conserve than theoretical counting capacity
of a bitstring.

I'm not sure what your point is here. I'm not remotely trying to argue this.

You made a point about HD ratio-

80% HD with 48 bits of network address still gives us
300,000,000,000 /48 networks (unless my math is very wrong). Again, I'm not sure how we're going to use that up in 50 or 100 years, but I'm sure history will prove me a fool.

-Don

25

Do you really think that today's allocations are going to be in use
(unchanged) when people are building homes out of IPv6-addressed
nanobots, or when people are trying to firewall the fridge from the TV
remote, etc.?

I certainly hope not- but then again I never thought IPv4 would be around this long either.

I understand trying to plan for the future, but if
someone is setting all this stuff up, getting a new (and larger) IPv6
block from their ISP is going to be the easiest part in the process.

You're right of course.

Again, why the hang-up on 8 bit boundaries? Why not /52 or /60? /60 is
not much bigger than /64, but /52 gives an end-site 16 times as many
subnets as /56 while giving the ISP 16 times as many blocks as /48.

Because byte alignment makes for shortcuts in routing softare/hardware allowing higher speeds? Because ARIN says so? :slight_smile:

-Don

26

Only assuming the nature of your mistake is 'turn it off'.

I can fat-finger a 'port-forward *all* ports to important internal
server', rather than just '80/TCP' pretty much exactly as easily as I can
fat-finger 'permit *all* external to important internal server' rather
than just '80/TCP'.

Which failure mode is more acceptable is going to depend on the business
in question too. If 'seconds connected to the Internet' is a direct
driver of 'dollars made', spending a length of time exposed (risk of loss)
while fixing a config error may well be preferable to spending a length of
time disconnected (actual loss).

I'll grant the 'everything is disconnected' case is easier to spot, though
- especially if you don't have proper change management to test that the
change you made is the change you think you made.

Regards,
Tim.

27

Only assuming the nature of your mistake is 'turn it off'.

I can fat-finger a 'port-forward *all* ports to important internal
server', rather than just '80/TCP' pretty much exactly as easily as I can
fat-finger 'permit *all* external to important internal server' rather
than just '80/TCP'.

Tim,

While that's true of firewalled servers that are intended to provide
services to the Internet at large, the vast majority of equipment
behind a typical NAT firewall provides no services whatsoever to the
Internet and do not each map to their own global IP address. They are
client PCs and a scattering of LAN servers.

You can fat-finger "allow all ports inbound" in a stateful firewall
far easier than you fat finger "translate a bank of global IP
addresses I don't actually have on a one-to-one basis to this large
list of local-scope IP addresses -and- allow all ports inbound" in a
NAT firewall. Actually, the latter is pretty hard to configure at all,
let alone fat-finger by mistake.

I'll grant the 'everything is disconnected' case is easier to spot, though
- especially if you don't have proper change management to test that the
change you made is the change you think you made.

Do you mean to tell me there's actually such a thing as a network
engineer who creates and uses a test plan every single time he makes a
change to every firewall he deals with? I thought such beings were a
myth, like unicorns and space aliens!

Regards,
Bill Herrin

28

Tim Franklin wrote:

29

In article <D03E4899F2FB3D4C8464E8C76B3B68B001AB7722@E03MVC4-UKBR.domain1.systemhost.net> you write:

> I'd rather push for /48 and have people settle on /56 than push for=20
> /56 and have people settle on /64.
=20
Again, why the hang-up on 8 bit boundaries?

Look, why are we arguing about this? Why not split
the difference? If /48 is too big and /64 is too small,
let's go halfway and use /56, OK?

This has the advantage that it is on a 4 bit nibble=20
boundary which makes it the boundary between network
and interface much clearer in writing
2001:3ff3:effe:1200::0/56=20
If you wrote 2001:3ff3:effe:12a0::0/56 then I would=20
immediately see that there are too many bits in the network
portion. It also avoids a messy situation with reverse
DNS delegations.

  And /48 is easier still.

  2001:3ff3:effe:1234:xxxx:xxxx:xxxx:xxxx
  <--ASSIGNED-->:<ME>:<------auto------->

30

Which is why, if your site has an *actual* clue, the deployed hosts *also*
have their own iptables/ipfilters/whatever-windows-calls-it rulesets that
say what hosts are allowed to talk to them. So on the server, I can do:

ip6tables -A tcp-in -s ! 2001:468:c80/48 -p tcp --dport 22 -j DROP

Now, even if our firewall guys fumble-finger something, I won't get
SSH connections coming in from outside AS1312.

Of course, I can't talk about business pressures from customers that have
incompetent security officers that don't understand stuff like multiple
layers of defense...

31

I've had to do this. When there's SLAs / money involved for failure,
you can't cowboy anything - because you're risking your job if you do.
Funny thing is, going through a "rehersal" before you make any change
increases significantly your chances of success - and now I prefer to
plan my changes in detail before I do them, as it makes me look a lot
better at my job.

A firewall change in particular, because of the security consequences
of mistake, justifies planning and review before implementation.

Regards,
Mark.

32

As much as I don’t want to resurrect this conversation again or beat a dead (now glued) horse: In the SOHO arena, today’s NAT users may or may not opt to use SPI down the road.

Many people just opt for the cheapest working solution and use defaults, so what we end up depends on what vendors like Linksys and Netgear decide. I am sure there will be customer demand for firewall functionality as well, but how much is not clear.

I am talking about SOHO users because they are a big portion of the large DDoS networks and an important frontier in the fight against worm propagation.

I know large mostly unused pools of client IP’s make it more difficult to use traditional worm propagation methods in IPv6[1], but if customers move from IPv4 “firewalls” to IPv6 “routers”, we still lose an important layer of security.

  1. worm propagation strategies in an IPv6 Internet - http://www.cs.columbia.edu/~smb/papers/v6worms.pdf
33

Seems like an understatement. Ipv6 addressing doesn't merely make
them more difficult,
they make traditional propagation methods and attack techniques that rely
on 'scanning' a network from outside impossible to execute.

If every subnet (end site) has a /64, and you can guess 16 of those
bits (say most
networks set the top 16 bits to zero and generate the rest using a
true random number
generator, for security's sake), there are so many IPs that random
scanning has a
probability of finding hosts so small, it is negligible....

It would take 9 years to probe 10% of the addresses of a single end site,
assuming you can scan 100,000 ips per second.

If the host id is sufficiently random or opaque to the outside world,
then this is
every bit as good as a well chosen password; it is essentially private, except
to nodes on the local subnet (who can monitor and ping multicast addresses).

I don't believe a worm can't effectively propagate and spend 10 years
trying to find
the IP address of the one or two computers at site X before moving to
site Z that
has 4 computers in a /64 some where...

A worm that has to connect to a remote machine would definitely have to
discern the IP through some method other than brute force scanning.

Such as a clean system contacting an infected system to make a request
(i.e. download a webpage) At which time the infected system stores
requestor's ip in a
database to probe later.

On the other hand, an IPv6 host could in theory bind a new IP address for each
group of web requests, not attach any listeners to that IP, and make
that IP cease to
exist after the web requests complete.

Since the /64 is so large... this essentially accomplishes what NAT
does for IPv4 users...
the IP address is private, by virtue of the fact, that the host
primary interface
address cannot be guessed.

Even if it is guessed, firewall rules may block traffic from the
probing address long
before they get close to randomly hitting a live IP :slight_smile:

34

I believe Steve Bellovin has already written extensively on this, and some
of the more plausible alternate non-scanning strategies for worm propagation.
I'm sure Steve has a pointer to the paper in question, which I've managed
to misplace in my senility... :wink:

35

Perhaps this one?

http://www.cs.columbia.edu/~smb/papers/v6worms.pdf

--Jeff

36

> I believe Steve Bellovin has already written extensively on this, and some
> of the more plausible alternate non-scanning strategies for worm propagatio

n.

> I'm sure Steve has a pointer to the paper in question, which I've managed
> to misplace in my senility... :wink:

Perhaps this one?

http://www.cs.columbia.edu/~smb/papers/v6worms.pdf

Yes, that's the one...

37

[lots of comments about the size of a /64]...

Am I the only one who imagines most ISPs will just assign the default IP to each /64 (or whatever they issue) (e.g. all zeros or mostly zeros or just the MAC addy of the end CPE)..

This would a) dramatically reduce the "breadth" of IPv6 space from a scanning perspective and b) even guessing MAC addys is not that hard given manufacturer codes.

IPv6 seems very, very classful to me, and I think the lessons we learned in the pre-CIDR days about amplification and address-guessing and topology determination by remote are still pretty relevant.

Obviously the firewall bit changes those expectations -- assuming they are used.

But if we assume that 2^96 is enough space to hide in... well, I'm pretty sure we'll see every kind of mess we've had to deal with in the past revisit their gifts upon us.

Deepak

38

It should probably be pointed out:

Asking for practical advice on choosing /48 vs. /56 on a residential broadband CPE is largely unanswerable.

Why?

Because I don't know of any residential broadband CPEs that support IPv6.

I want to be wrong about that. Seriously. Send me a link to one. I want to be wrong. (And by residential, I mean a CPE/router/firewall that costs
less than $150US.)

IMO, the only answers so far:

  businesses get /48
  dialup gets /64

(by default anyway; there are always exceptions)

John

40

Asking for practical advice on choosing /48 vs. /56 on a
residential broadband CPE is largely unanswerable.
Because I don't know of any residential broadband CPEs that
support IPv6.

If you go to

there is at least one presentation from Comcast, a residential
broadband provider who explained that they simply cannot continue
in business without IPv6. They started IPv6 deployment planning
in 2005. If you don't know of CPE that supports IPv6, maybe you
should ask a broadband ISP that is serious about surviving in business
past the crunch of 2010.

I want to be wrong about that. Seriously. Send me a link to
one. I want to be wrong. (And by residential, I mean a
CPE/router/firewall that costs less than $150US.)

http://wiki.openwrt.org/IPv6_howto
Clearly, this CPE is based on Linux which has had full IPv6 support
for many years, including things like firewalling, transition mechanisms
like 6to4, DNS and so on. Given the realities of today's low-end network
device manufacturing (centered in China where IPv6 is already being
deployed, and based on standard hardware designs that are differentiated
by software, plastic case design, and packaging) it should take about
two months from time of order for mass quantities of CPE devices to
appear on the market. The software is already done, the standard
hardware
designs are fully capable of IPv6. All they are waiting for is customers
like Linksys to place an order.

IMO, the only answers so far:
  businesses get /48
  dialup gets /64

Wrong!
The answer so far is that EVERYBODY gets a /48, but if you think that
there is a risk that you won't be able to get additional /32s when you
outgrow your first allocation, then give a /56 to RESIDENTIAL SITES.
This is not the same as dialup, i.e. residential sites could be
connected
with DSL, T1s, wireless, or whatever. In fact, if a business is
connected
via dialup, you should give them a /48, because businesses have a habit
of
continuous growth, unlike residences which tend to top out at 5 or 6
residents.

--Michael Dillon