Subject: Re: Why /64

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 01 Nov 2013 21:08:28 -0400

On 2013-10-31 10:53 PM, "Karl Auer" <[email-masked]> wrote:

>On Fri, 2013-11-01 at 00:59 +0000, Manfredi, Albert E wrote:
>> Why would you need 2^64 IIDs for a subnet of neighborhood streetlights,
>>for instance?
>
>I don't know. But the key thing is that I don't need to. When I ask for
>a glass of water at a restaurant, I do not know or care how many water
>molecules I'm buying, either. It doesn't *matter*.
>
>No-one ever seems to consider the *advantages* of the "/64 everywhere"
>approach. They decry the "waste" without looking at what that "waste" is
>buying:

I think this is a very important point.  I think many (as did I at first),
attempt to rationalize how much space we are wasting, then over time
realized the operational and practical benefits of a standard subnet size
(ops hat on).

>
>- everything is the same. No more calculating (leaf) subnet sizes, no
>more stealing from Peter to pay Paul, no more getting it wrong - every
>subnet is a /64.
>
>
>
>- there are *always* enough addresses in *any* subnet for you add one
>more device. Or even a hundred. You might run into other limits, but the
>addressing will never get in your way.
>
>- adding a subnet is easy - just take the next /64. No estimates,
>calculations, consideration or judgement needed.

There has been significant simplification on how IP address space in
operator networks (and I suspect other places) is now deployed.  In my
experience, this simplification also applied our management network side
(akin to Enterprise network structure).  A significant amount of
operational effort is expended in IPv4 sizing, and re-sizing address
blocks.  I understand that having sizes like /80 may still be big enough
not to require re-sizing - but /64 sure seems like enough for almost any
subnet zone we can contemplate.  I am sure, maybe one day we will have a
new use case decades from now, but assuming that more prefixes (using
smaller blocks) will satisfy this unknown requirement is a stretch.

What we do know is that there is signifiant benefits from standard subnets
sizes today deploying IPv6 for the first time.

>
>- your router configs are easier to understand
>
>- your documentation is easier to write and easier to read.
>

Not only is the documentation easy and less prone to error (which is an
endless battle with IPv4), it also greatly simplifies security
configuration and policy.  Working with variable subnet lengths adds
complexity to the design and management process in networks.

I am not saying that these points should stop us from considering other
subnet lengths, but as noted by Karl above, we should evenly weigh the
operational advantages.

Lastly, I have not actually seen a convincing  problem statement for this
(similar to Erik's comments earlier in the thread).  I have seen many
what-if statements, but perhaps a clearly written draft with some use
cases may be helpful (I did not find the car example very compelling since
I can just assign a /56 or /48 to the care if multiple subnets are
required there).

Regards,

Victor K

>
>
>Regards, K.
>
>-- 
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Karl Auer ([email-masked])
>http://www.biplane.com.au/kauer
>http://twitter.com/kauer389
>
>GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
>Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

---

From: Ray Hunter <[email-masked]>
Date: Sun, 03 Nov 2013 08:43:59 +0100

> I can just assign a /56 or /48 to the care if multiple subnets are

How about http://tools.ietf.org/html/rfc6583?

6.2.  Minimal Subnet Sizing

   By sizing subnets to reflect the number of addresses actually in use,
   the problem can be avoided.

That breaks today's SLAAC.

To your point that the case for dropping /64 is based mainly on "what if
statements", AFAICS SLAAC is the only hard argument for maintaining /64.
The rest of the points seem to be pretty soft operational arguments. I
like these, but I don't think they stack up against a (potential) DDOS
target.

regards,

-- 
Regards,
RayH

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 3 Nov 2013 01:41:37 -0700 (PDT)

----- Original Message -----
> From: Ray Hunter <[email-masked]>
> To: Victor Kuarsingh <[email-masked]>
> Cc: [email-masked]
> Sent: Sunday, 3 November 2013 6:43 PM
> Subject: Re: Re: Why /64
> 
> 
> 
> Victor Kuarsingh wrote:

And it isn't acknowledging the costs or drawbacks of doing so. That advice is only practical for people who understand networking and are in a position to size/resize subnets.

It isn't appropriate for the dominant type of network - the home network "operated" by non-network operators. To cater for them, either IPv6 NAT will need to be deployed (and then operators will give out /128s) with /64s behind them (again achieving the simplicity of an "excessively" sized subnet, as has happened in residential networks with RFC1918s and IPv4 NAT), or automated methods to grow or shrink the number of addresses in a subnet will need to be developed and deployed. I think the latter option would be much better than IPv6 NAT, but much harder to develop and deploy. So a lot of the effort to restore end-to-end and to avoid the costs of NAT traversal we've seen in IPv4 will have been wasted.

> statements", AFAICS SLAAC is the only hard argument for maintaining /64.

I think the benefits of things such as opaque IIDs are a hard argument. If subnets are shrunk down to the number of actual hosts attached, the level anonymity that opaque IIDs will provide disappear, as it would for existing "privacy addresses", and subnets become vulnerable to unsolicited ingress address scanning attacks again.

> like these, but I don't think they stack up against a (potential) DDOS

A DDoS on a neighbor cache is a resource exhaustion attack. If you can prevent the neighbor cache resources being totally exhausted, while still providing degraded service rather than a total denial of service, then I think the value of the this type of attack is significantly reduced. 

My proposal, which Ray, Karl and others kindly reviewed and provided comments on, is to take advantage of IPv6's best-effort (or "unreliable") nature, and origin hosts' ability to recover from packet loss, by retransmitting.

Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless Neighbor Presence Discovery

Abstract One of the functions of IPv6 Neighbor Discovery is to discover whether a specified neighbor is present.  During the neighbor presence discovery process state is created.  A node's capacity for this state can be intentionally exhausted to perform a denial of service attack, known as the "Neighbor Discovery DoS Attack".  This memo proposes a stateless form of neighbor presence discovery to prevent this Neighbor Discovery DoS Attack.

http://tools.ietf.org/html/draft-smith-6man-mitigate-nd-cache-dos-slnd-06

It's not perfect, I think the only way to actually completely eliminate this neighbor cache vulnerability is to move to a node registration model (i.e., no "discovery" occurring). However there needs to be an interim solution, and I think the above would be reasonable.

I've been meaning to get back to it for a while, to make some further minor changes. Otherwise I think it is at a point where I'd propose it for adoption. I'd be interested if others think it is worthwhile.

Thanks,
Mark.

---

From: Ray Hunter <[email-masked]>
Date: Sun, 03 Nov 2013 10:27:04 +0100

> Mark ZZZ Smith <mailto:[email-masked]>
> 3 November 2013 09:41
>
It is a way of containing the problem.

What practical problem would there be if some Homenet router
manufacturers shipped with /96 or /112 prefix length as default, instead
of /64?

[given that Homenet figures out little-conf]

> It isn't appropriate for the dominant type of network - the home network "operated" by non-network operators. To cater for them, either IPv6 NAT will need to be deployed (and then operators will gi…
I don't pretend to be able to predict the future.

Allocating a single /64 per home is also harmful, because it prevents
multiple prefixes in the home.

However there's a significant difference to IPv4 history. IPv4 addresses
were scarce. There was a commercial benefit to only allocating a /32.
There is no commercial benefit to allocating a /128 instead of a /64 AFAICS.

There is currently some technical benefit to delegating a single /64
AFAIK (due to broken implementations on the carrier side) which will
hopefully go away over time.

Enforcing use of SLAAC (a technical measure) to overcome delegation of a
single /128 (bad operational practice) is an equally bad idea IMHO.

And anyway, ISP's could enforce /128 allocations just as easily today if
they really wanted to, even with the /64 barrier: either using dynamic
ACL's and DHCPv6, or some other existing first hop security mechanism
that limits the user to one IPv6 address per physical port.
> I think the benefits of things such as opaque IIDs are a hard argument. If subnets are shrunk down to the number of actual hosts attached, the level anonymity that opaque IIDs will provide disappea…
There could still be opacity (at the prefix level, rather than at the
LAN/host level)

/64 is a really big number. The focus is ND today.

In reality, anything anywhere that has to maintain any state whatsoever
that is linked to an individual IPv6 address is a legitimate
resource-exhaustion target.
> A DDoS on a neighbor cache is a resource exhaustion attack. If you can prevent the neighbor cache resources being totally exhausted, while still providing degraded service rather than a total denia…

True.
> I've been meaning to get back to it for a while, to make some further minor changes. Otherwise I think it is at a point where I'd propose it for adoption. I'd be interested if others think it is wo…

I see these mechanisms as being complementary, rather than mutually
exclusive.

Limiting prefix length even a few bits longer than /64 could
significantly reduce the difficulty of making an implementation
resilient to resource exhaustion e.g.  you could use a divide and
conquer approach to rate limiting "in buckets" so that fewer nodes are
under attack, whilst the total number of buckets you require for
tracking can be limited to match your local hardware.

That argument is equally valid for any device that has to track state
linked to an individual IPv6 address (including firewalls, load
balancers, translators, and a whole bunch of middleware boxes)

I think insisting on a blanket /64 creates a problem elsewhere: we are
then effectively saying that no device or protocol on the Internet can
be stateful in any meaningful way at an individual IPv6 address level.

-- 
Regards,
RayH

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 03 Nov 2013 10:58:01 +0100

> That breaks today's SLAAC.

I agree, and I think, in more detail, it breaks SLAAC over Ethernet and 
its derivatives.

Alex

---

From: Karl Auer <[email-masked]>
Date: Sun, 03 Nov 2013 21:54:41 +1100

> like these, but I don't think they stack up against a (potential) DDOS

Hm. Definite major cost savings across the network against a risk is a
soft operational argument? You must work with a different class of bean
counter to the ones I've worked with :-)

But don't take my word for it (hah!). Run the numbers. Use reasonable
estimates for the costs to be saved and reasonable estimates for the
possible cost of a DDOS, multiply both by the appropriate risk factors
over time and see which course is the most reasonable.

Regards, K.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 3 Nov 2013 23:03:01 +0900

> manufacturers shipped with /96 or /112 prefix length as default, instead

For one, a large installed base of existing hosts (i.e., all hosts that
don't support $configprotocol) won't be able to get on to the network. This
is true even if you pick $configprotocol = DHCPv6, because there are lots
of hosts that don't implement it. It seems unfortunate to ship a solution
that won't work with all existing hosts.

Also, what's the advantage of such an approach? You're not suggesting that
a home gateway will be able to resist a DoS attack just because its links
are downgraded from /64 to /96, are you?

> be stateful in any meaningful way at an individual IPv6 address level.

I see advantages to that. Maintaining lots of state in the network doesn't
scale and, by breaking end-to-end, complicates applications. Better to
design things so the network doesn't need to keep per-IP address state.

In an ISP, you can keep per-customer state, or perhaps even per-subnet
state; why do you need more than that? If you're not an ISP and are in
control of the IP addresses you hand out, then you can always just hand out
fewer addresses. If you want you can give every subnet a /120 -/128 like we
do in IPv4 and have fun managing address pools like we do in IPv4.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Nov 2013 05:31:51 +1300

Ray,

> Victor Kuarsingh wrote:

...
> That breaks today's SLAAC.

It would, so it's currently useless advice, indeed, and the counter-argument
is that it makes host addresses much easier to guess once you have
identified a prefix (i.e. if prefix:1 responds, you can guess that prefix:2
through prefix:254 also exist). I think you've found a serious bug in RFC 6583.

Fortunately section 6 of RFC 6583 contains several other mitigations.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Sun, 03 Nov 2013 21:57:16 +0100

> Brian E Carpenter <mailto:[email-masked]>
> 3 November 2013 17:31
> Ray,
>
I think the list is underestimating the number of middleware boxes
employed in enterprise networks.

If the first virus or worm like Code Red or Code Blue can take down a
whole IPv6 network by simple resource exhaustion of some downstream
devices, there's something seriously wrong. Indeed simple BCP38 egress
and ingress access lists saved many people's skins during those
incidents, and I hope we've learned from them.

I disagree that it's currently useless advice in RFC6583 (having
contributed text to this draft myself).

One workaround for the problem you mention is to move the "opacity" into
the prefix portion of the IID address space.

You can easily configure a prefix/VLAN almost per host with modern L3
switches at very little cost. ACL's are also often pre-compiled and are
pretty efficient to process.

So in front of the "sensitive' middleware box at the ingress to a site,
it'd be fine to have multiple static ACL filters of <site>:<a>::/120
<site>:<b>::/120 <site>:<c>::/120... <site>:<n>::/120

where <site> is one or more site prefixes to /64 level, and <a>,<b>,<c>
... <n> are seemingly "random" strings of 56 bits that provide opacity
in the IID portion from the bits /64 to /120 (starting with 000 for
static assignments to avoid any compatibility issues).

Then the middleware box would only have to deal with at max n*2^8
addresses in any stateful lookup tables, which is easily do-able, even
in poorly implemented software.

That's many orders of magnitude less than 2^64, and much less draconian
than having to force all middleware boxes to perform only stateless
handling.
Some things, like fragmentation reassembly, simply cannot be made stateless.

And off-site attackers should still find it equally difficult to perform
cross-host correlation attacks as if every LAN truly was a /64, because
they'd have trouble learning <a> <b> <c> ... <n>.

IMHO It'd be "nice" from an organisational and administration
perspective if all of that filtering magic could happen in the data
centre LAN switch fabric, whilst hosts could still perform SLAAC on the
longer /120 masks, rather than having to be manually statically configured.

regards,

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Nov 2013 12:48:04 +1300

> the prefix portion of the IID address space.

If I am watching traffic from your site, I will pick up valid host addresses
and I can base my scanning attack on addresses close to each of those
valid addresses, without even needing to know the prefix length. I just
scan address+-1, address+-2, and so on. I will find all your hosts.
No need to DOS the infrastructure; more fun to DOS the hosts.

Regards
   Brian

---

From: Ray Hunter <[email-masked]>
Date: Mon, 04 Nov 2013 17:34:22 +0100

> 4 November 2013 00:48

If you are doing that sort of traffic observation, then opacity based on
SLAAC + /64 is equally irrelevant, which was one of your original
objections to increasing prefix length in the first place. The
workaround was to address your concerns on opacity, not to avoid DDOS on
individual hosts.

> Ray Hunter <mailto:[email-masked]>
> 3 November 2013 21:57
> Ray Hunter <mailto:[email-masked]>
> 3 November 2013 08:43
> Victor Kuarsingh wrote:
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Nov 2013 06:03:57 +1300

On 05/11/2013 05:34, Ray Hunter wrote:
> SLAAC + /64 is equally irrelevant, 

Not at all. Finding one host in a /64 gives me no help at all in guessing
a second host in the same /64, unless the network is foolish enough
to number its hosts with consecutive numbers.

I am currently 2001:67c:370:160:28cc:dc4c:9703:6781.
That gives you no clue about any other host in 2001:67c:370:160::/64

I am also 31.133.165.38. That gives you a very strong clue about at
least 126 other possible hosts. I've just found two of them
after only 5 tries.

   Brian

> which was one of your original

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 4 Nov 2013 21:09:34 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian
> E Carpenter

> least 126 other possible hosts. I've just found two of them

In fact, the situation is very similar with IPv4 and NAT, except that IPv4 plus NAT is the equivalent of 32 bits of prefix and 32 bits of IID. I can set up my home modem/router, not to mention the WiFi access point downstream of that, to give out addresses that would also be difficult to guess.

I think that even if an ISP hands out /64s, if someone wants to break that up into different subnets, the argument that this shouldn't be done because the IIDs are easier to guess doesn't seems a strong argument to me. I'll buy the argument that it's easier for operators to have a consistent length IID, but it just sounds a bit like saying that classful addresses were easier to manage.

Bert

---

From: Karl Auer <[email-masked]>
Date: Tue, 05 Nov 2013 09:01:04 +1100

On Mon, 2013-11-04 at 21:09 +0000, Manfredi, Albert E wrote:
> I'll buy the argument that it's easier for operators to have a
> consistent length IID, but it just sounds a bit like saying that
> classful addresses were easier to manage.

They were - far easier. But IPv4 address scarcity forced CIDR on us.
While CIDR rescued us for a little while from the strictures of a small
address space, it also pushed us into a maze of twisty little tunnels,
all different. There ain't no such thing as a free lunch.[1]

I hated CIDR at first. It complicated my life and meant I was
calculating stuff all the time. I got it wrong a lot :-). Up until then
everything in my world had been 255.255.255.0. I recall a LOT of people
being in a love/hate relationship with CIDR, especially during the
period where some stuff didn't support it yet. The DNS never did catch
up. But CIDR was a necessary evil, so the world went from three standard
subnet sizes to a welter of variation that has been causing frustration
and error ever since, with the pain steadily increasing as IPv4 address
scarcity bit deeper.

The 64-bit IID size gives us back all the advantages of the pre-CIDR
world, and none of the disadvantages (NDCE is a new thing).[2]

IPv6 *has* CIDR. You can have subnets of any size you like. Only if you
want to use SLAAC are you limited to /64 subnets. Sure the standard
says /64, but in the privacy of your own network, you can do as you
please. There are plenty of people doing very strange things with IPv4
inside their networks, and if you want to commit self-harm with IPv6
too, no-one can stop you.

Regards, K.

[1] The price of IPv6 is a protocol change. Definitely not free :-(

[2] The fear that we will run out of IPv6 address space because of
64-bit IIDs is IMHO misplaced, but I won't rehash the arguments.

---

From: Ray Hunter <[email-masked]>
Date: Mon, 04 Nov 2013 23:26:16 +0100

> 4 November 2013 18:03
The point is that you don't have to find *any* nodes on a /64. Not one.

You just send any old garbage to a bunch of addresses so any middle box
or multicast listening node or last hop router is required to commit
state for any length of time, and wait for it to run out of resources
eventually.

The poor middleboxes or routers upstream of a secure zone can't filter
or rate limit with a "permit unless" rule as they don't know what is
downstream, and that requires state to learn the attackers dynamically.
Your own firewall or router becomes the attack target.

I think Mark Smith is right. The only true solution is for nodes
residing in a trusted zone to regularly register their presence to the
upstream nodes or routers, so that the upstream nodes or routers can
apply a blanket "deny unless" filtering rule.

Then you might get your wish for fragmentation and other useful stateful
operations to be permitted through firewalls.

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Nov 2013 12:27:58 +1300

> apply a blanket "deny unless" filtering rule.

Yes, white listing the valid addresses would certainly work
(if it would scale).

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 04 Nov 2013 19:15:52 -0800

Ray,

Whether it does depends on your definition of SLAAC.

FWIW RFC 4862 "Stateless Address Autoconfiguration" doesn't have any 
notion of /64 (quite intentionally) but instead talks about 
concatenating the prefix with the IID. Hence that RFC can support 
different prefix/IID lengths.

RFC 2464 (and many similar RFCs) specify in section 4 that the IID is a 
modified EUI-64 hence 64 bits long.

Whether implementations can handle different IID lengths, or whether 
other RFCs have or have not hard-coded a /64 are different matters. But 
SLAAC as in the RFC doesn't break.

    Erik

---

From: 神明達哉 <[email-masked]>
Date: Tue, 5 Nov 2013 18:49:52 -0800

At Mon, 04 Nov 2013 19:15:52 -0800,
> different prefix/IID lengths.

Right, RFC 4862 explicitly notes that in Section 5.5.3:

      [...]  Thus, an implementation should not assume a
      particular constant.  Rather, it should expect any lengths of
      interface identifiers.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Nov 2013 18:31:58 +0900

> Your own firewall or router becomes the attack target.

It's trivial to defend against this on the last-hop router. Just prioritize
existing neighbour cache entries over new entries and glean addresses from
local NS/NA packets. There's already running code that does this.

If you want to do this on a firewall a few hops away, then just prioritize
state table entries for IP addresses that have seen two-way communications
and rate-limit the rest if you're under attack. You're already keeping
per-IP state, obviously, so the total amount of state that needs to be
maintained is roughly the same.

Chances are that if you're doing this for security reasons, you're probably
not allowing incoming session requests anyway, so you can just junk inbound
DoS attacks without ever creating any state at all.

Sure, inside hosts can still DoS you by creating random state entries, but
they can already do this, even in IPv4, because they have access to 64k
ports and lots and lots of destination addresses (order of 2^32) that they
can use to overflow your cache (or, possibly, the address*port product of
your outside NAT pools).

> apply a blanket "deny unless" filtering rule.

No, you just need to be a tiny bit more sophisticated than you are in IPv4.

What I can't understand is that what we have in IPv4 today is *already*
much more complicated than this. We have extremely complicated and
massive-state-maintaining NAT boxes and ALG/firewalls just to keep IPv4
running. IPv6 offers a simpler design and makes things easier to understand
on the local link, and suddenly the problem is now too huge for us to solve?

---

From: Ray Hunter <[email-masked]>
Date: Wed, 06 Nov 2013 15:35:10 +0100

> Lorenzo Colitti <mailto:[email-masked]>
> 6 November 2013 10:31
> <snip>
No, it's just a different problem. Scarcity of downstream (and to some
extent upstream) IPv4 addresses protected a lot of potentially bad code
from exploitation.

We're now going to discover who was swimming naked, as Warren Buffett
would say.

-- 
Regards,
RayH