Subject: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Jan 2014 11:07:04 +1300

Hi,

A group of us put this together following a discussion some weeks
ago on the v6ops list about the 64-bit boundary in IPv6 addresses.
Discussion belongs in 6man, please.

This draft is incomplete but we'd welcome input. Let me underline
an important comment in the introduction:

  _The purpose of this document is to analyse the issues around this
   question.  We make no proposal for change, but we do analyse the
   possible effects of a change._

   Brian + co-authors

-------- Original Message --------
Subject: I-D Action: draft-carpenter-6man-why64-00.txt
Date: Sun, 05 Jan 2014 13:59:17 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Analysis of the 64-bit Boundary in IPv6 Addressing
        Authors         : Brian Carpenter
                          Tim Chown
                          Fernando Gont
                          Sheng Jiang
                          Alexandru Petrescu
                          Andrew Yourtchenko
	Filename        : draft-carpenter-6man-why64-00.txt
	Pages           : 14
	Date            : 2014-01-05

Abstract:
   The IPv6 unicast addressing format includes a separation between the
   prefix used to route packets to a subnet and the interface identifier
   used to specify a given interface connected to that subnet.
   Historically the interface identifier has been defined as 64 bits
   long, leaving 64 bits for the prefix.  This document discusses the
   reasons for this fixed boundary and the issues involved in treating
   it as a variable boundary.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-carpenter-6man-why64-00

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 6 Jan 2014 16:07:49 +0000

Hello Brian and co-authors,

The draft looks good to me. In Section 3, paragraph 3, please
add ISATAP [RFC5214] and AERO [I-D.templin-aerolink] to the
list of "IPv6-over-foo" documents.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Sunday, January 05, 2014 2:07 PM
> To: 6man
> Subject: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]
> 
> Hi,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 6 Jan 2014 12:51:44 -0800 (PST)

Hi,

I've had a quick read through, I think this document would be quite useful.

One thing I think would be good to capture is a bit of the history/rational behind the choice of 64 IID. 

I became aware of that history via Christian Huitema's "IPv6: The New Internet Protocol (2nd Edition)" book, I think it would be good if that history was a bit more widely available to explain and justify the choice.

Regards,
Mark.

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: 6man <[email-masked]>
> Cc: 
> Sent: Monday, 6 January 2014 9:07 AM

---

From: Ray Hunter <[email-masked]>
Date: Tue, 07 Jan 2014 12:11:34 +0100

> http://tools.ietf.org/html/draft-carpenter-6man-why64-00
I have read this draft.

some comments:

Where exactly is the requirement that IPv6 has to use /64 prefix length 
really enshrined?
I think the draft can help clarify that, and that alone makes it 
worthwhile proceeding.

I humbly disagree with the conclusions in Section 9.

The argument seems to assume that all n hosts must be allocated within 
one single prefix with a prefix length >> 64.
Therefore it assumes that increasing prefix length reduces attack search 
space (given some knowledge of one or more active IPv6 addresses)

IMHO Address space is address space. Allocation density is allocation 
density. IPv6 supports multiple prefixes per link and the concept of 
determining "on link prefixes" via rfc5942 (unlike the "subnet mask" 
mechanism of IPv4).

It should be perfectly feasible to allocate a /64 to a router interface 
in an IPAM tool, but then configure the equivalent of n prefixes each 
containing 1 or 2 address with prefix length /128 or /127 (depending on 
the implementation) for n hosts and which are equally sparsely assigned 
across the /64, and all sharing a single L2 link. Even end node to end 
node communication should flow directly (avoiding the router) as these 
prefixes could be marked "on link" via the AdvOnLinkFlag = L flag.

Anyway, in the majority of modern day wired deployments, the delta cost 
of L3 over L2 is minimal, as the most dominant form of wired LAN 
(Ethernet) are commonly switched in silicon, and multicast has to be 
emulated. Wired Ethernet has in effect become a point to point protocol. 
So deploying a dedicated L3 connection per end host is both technically 
and financially feasible, and may have significant operational benefits 
in certain scenarios. Allocating a /64 for each such port on a L3 switch 
is sub optimal IMHO. And by the same privacy argument, allocating n 
hosts sparsely over a single /64 of address space spread over multiple 
L3 interfaces would have the same net effect for off-net attackers as n 
hosts sharing a flat L2 LAN using a single /64, with the added advantage 
that even locally the individual end nodes would not be able to 
passively observe each other's traffic or addresses (advantageous in 
shared hosting environments).

An attacker that happens to discover the address of node A would not 
find this information helpful in attempts to locate node B, any more 
than if it were a flat /64.

So to me it's a non-relevant argument one way or the other.

Section 2.2

It may not be a widely held belief, but I remain concerned about the 
potential for resource exhaustion for any number of processes due to the 
"massive over sizing" of prefixes to /64: any number of untested 
processes that track state based on /128 IPv6 address could be attacked. 
The flip side of expanding privacy through address obfuscation at IID 
level is that the source space available for attacks also increases. ND 
cache exhaustion is probably just the first issue we've discovered of 
many that exist. This may have knock on operational consequences, which 
in the IPv4 world have relied on the scarcity of IPv4 address space to 
be able to operate correctly under stress scenarios. We're going to 
discover who has been swimming naked when the tide goes out. Call that 
FUD, or operational expediency, whichever you like. BCP38 has saved me 
on a number of occasions when all else has failed.

-- 
Regards,
RayH

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Jan 2014 14:22:37 +0100

> list of "IPv6-over-foo" documents.

Hi Fred,

Yes, IID of ISATAP RFC5214 reads as fixed 64bit long, and should be cited.

However, I am not sure ISATAP would apply to be an 'IPv6-over-foo' 
document.  Rather a v4-v6 transition mechanism?  If yes we have this 
text that could  be augmented with ISATAP reference:
>    IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic
>    transition and Teredo rely on the use of IIDs of length 64.

On another hand,  draft-templin-aerolink-00.txt seems to be an 
IPv6-over-foo document.  I need to read this part more to better 
understand the suggestion. I will come back.

Thanks for the suggestion.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Jan 2014 15:59:36 +0000

Hi Alex,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Tuesday, January 07, 2014 5:23 AM
> To: [email-masked]
> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]
> 

ISATAP specifies the formation of IPv6 interface identifiers and the
operation of IPv6 neighbor discovery over a link type that supports
the transmission of IPv6 packets, so it fits the description of IPv6
over (foo).

> document.  Rather a v4-v6 transition mechanism?

Some sites that deploy ISATAP may find the service acceptable to the
point that they never have to take it down and move onto native IPv6.
I think that's part of the reason why there is so much teeth-gnashing
among the haters who have pushed back on ISATAP over the years.

> If yes we have this

OK - thanks.

Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Jan 2014 17:58:26 +0100

Hi Fred,

> the transmission of IPv6 packets, so it fits the description of IPv6

Sounds more like the IPv6-over-PPP part of the IP-over-foo family, in 
that PPP like ISATAP link layer is a sort of a dummy virtual link.  (a 
more real IP-over-foo document would have e.g. a particular PHY).

Let's see where we'll put this reference.

>> understand the suggestion. I will come back.

Ok, let's see.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Jan 2014 17:10:58 +0000

Hi Alex,

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Tuesday, January 07, 2014 8:58 AM
> To: Templin, Fred L; [email-masked]
> that PPP like ISATAP link layer is a sort of a dummy virtual link.

RFC4861 says:

   "Unless specified otherwise (in a document that covers operating IP
   over a particular link type) this document applies to all link types.
   However, because ND uses link-layer multicast for some of its
   services, it is possible that on some link types (e.g., Non-Broadcast
   Multi-Access (NBMA) links), alternative protocols or mechanisms to
   implement those services will be specified (in the appropriate
   document covering the operation of IP over a particular link type).
   The services described in this document that are not directly
   dependent on multicast, such as Redirects, Next-hop determination,
   Neighbor Unreachability Detection, etc., are expected to be provided
   as specified in this document.  The details of how one uses ND on
   NBMA links are addressed in [IPv6-NBMA].  In addition, [IPv6-3GPP]
   and[IPv6-CELL] discuss the use of this protocol over some cellular
   links, which are examples of NBMA links."

ISATAP is a document that covers operating IP over a particular link
type. ISATAP links are NBMA, and ISATAP specifies the operation of
IPv6 ND over that link type.

> (a more real IP-over-foo document would have e.g. a particular PHY).

ISATAP links are very real; the PHY is the underlying IPv4 site.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Jan 2014 18:45:18 +0100

> ISATAP links are very real; the PHY is the underlying IPv4 site.

I don't doubt ISATAP links are real links which transport real packets.

But a PHY would have a specific encoding scheme (OFDM, TDMA, etc.), 
which IPV4 had not.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Jan 2014 17:49:46 +0000

Hi Alex,

> But a PHY would have a specific encoding scheme (OFDM, TDMA, etc.),

That doesn't matter. What matters is that ISATAP (like AERO) specifies
the generation of IPv6 interface identifiers which are 64-bits in
length - which is exactly the subject your document is addressing.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jan 2014 08:22:26 +1300

> length - which is exactly the subject your document is addressing.

I agree with Fred. Actually for completeness we should list
RFC 2529 (6over4) too, although it is unused today as far as I know.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jan 2014 08:32:30 +1300

Hi Ray,

Thanks for the comments.

On 08/01/2014 00:11, Ray Hunter wrote:
...
> Where exactly is the requirement that IPv6 has to use /64 prefix length

I don't think it is enshrined in any one place; in fact at one level
the architecture carefully avoids it.

> one single prefix with a prefix length >> 64.

That is a very common deployment model, surely? I don't think the death
of the L2 switch has been declared yet; I see plenty of them around.

I agree that it *could* be done differently as you describe below.

> many that exist. 

That is a bit of a vague argument to put in an RFC though. Can you find at
least one example of such an attack?

     Brian

> This may have knock on operational consequences, which

---

From: Tim Chown <[email-masked]>
Date: Tue, 7 Jan 2014 19:36:06 +0000

Hi Ray,

It would be good to suggest specific text/edits.

Tim

On 7 Jan 2014, at 11:11, Ray Hunter <[email-masked]> wrote:

> Where exactly is the requirement that IPv6 has to use /64 prefix length really enshrined?
> I think the draft can help clarify that, and that alone makes it worthwhile proceeding.
> 
> 
> The argument seems to assume that all n hosts must be allocated within one single prefix with a prefix length >> 64.
> Therefore it assumes that increasing prefix length reduces attack search space (given some knowledge of one or more active IPv6 addresses)
> 
> IMHO Address space is address space. Allocation density is allocation density. IPv6 supports multiple prefixes per link and the concept of determining "on link prefixes" via rfc5942 (unlike the "subnet mask" mechanism of IPv4).
> 
> It should be perfectly feasible to allocate a /64 to a router interface in an IPAM tool, but then configure the equivalent of n prefixes each containing 1 or 2 address with prefix length /128 or /127 (depending on the implementation) for n hosts and which are equally sparsely assigned across the /64, and all sharing a single L2 link. Even end node to end node communication should flow directly (avoiding the router) as these prefixes could be marked "on link" via the AdvOnLinkFlag = L flag.
> 
> Anyway, in the majority of modern day wired deployments, the delta cost of L3 over L2 is minimal, as the most dominant form of wired LAN (Ethernet) are commonly switched in silicon, and multicast has to be emulated. Wired Ethernet has in effect become a point to point protocol. So deploying a dedicated L3 connection per end host is both technically and financially feasible, and may have significant operational benefits in certain scenarios. Allocating a /64 for each such port on a L3 switch is sub optimal IMHO. And by the same privacy argument, allocating n hosts sparsely over a single /64 of address space spread over multiple L3 interfaces would have the same net effect for off-net attackers as n hosts sharing a flat L2 LAN using a single /64, with the added advantage that even locally the individual end nodes would not be able to passively observe each other's traffic or addresses (advantageous in shared hosting environments).
> 
> An attacker that happens to discover the address of node A would not find this information helpful in attempts to locate node B, any more than if it were a flat /64.
> 
> It may not be a widely held belief, but I remain concerned about the potential for resource exhaustion for any number of processes due to the "massive over sizing" of prefixes to /64: any number of untested processes that track state based on /128 IPv6 address could be attacked. The flip side of expanding privacy through address obfuscation at IID level is that the source space available for attacks also increases. ND cache exhaustion is probably just the first issue we've discovered of many that exist. This may have knock on operational consequences, which in the IPv4 world have relied on the scarcity of IPv4 address space to be able to operate correctly under stress scenarios. We're going to discover who has been swimming naked when the tide goes out. Call that FUD, or operational expediency, whichever you like. BCP38 has saved me on a number of occasions when all else has failed.
> 
> 
> -- 
> Regards,
> RayH
>

---

From: Tim Chown <[email-masked]>
Date: Tue, 7 Jan 2014 19:35:20 +0000

> RFC 2529 (6over4) too, although it is unused today as far as I know.

Yeah, I thought this was a bit of a diversion, but I agree it’s a necessary rathole for completeness, whether anyone uses ISATAP or not.  Likewise 6over4.

So I looked at some other transition tools.  e.g. 6rd says (section 4 of RFC5969) that “a 6rd delegated prefix SHOULD be /64 or shorter”.  No MUST, presumably for ISPs that for some reason just give a customer one IPv6 address.  For 6to4, section 2 of RFC3056 implies use of /64.  Maybe we can just have a short section listing what each mechanism says, where at the moment I think we just have one sentence in section 3 ("IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic transition and Teredo rely on the use of IIDs of length 64.“)

Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 7 Jan 2014 19:54:42 +0000

Hi Tim,

> From: Tim Chown [mailto:[email-masked]]
> Sent: Tuesday, January 07, 2014 11:35 AM
> To: Brian E Carpenter
> Cc: Templin, Fred L; Alexandru Petrescu; [email-masked]
> Yeah, I thought this was a bit of a diversion, but I agree it's a necessary rathole for completeness,
> whether anyone uses ISATAP or not.  Likewise 6over4.

Thanks, but please don't forget that ISATAP (and AERO and 6over4) are
IPv6-over-(foo) documents in that they specify the IPv6 interface
identifier format and the operation of IPv6 ND over specific link
layers (which as Alex agreed are real links which transport real
packets).

Thanks - Fred

> So I looked at some other transition tools.  e.g. 6rd says (section 4 of RFC5969) that "a 6rd
> delegated prefix SHOULD be /64 or shorter".  No MUST, presumably for ISPs that for some reason just
> give a customer one IPv6 address.  For 6to4, section 2 of RFC3056 implies use of /64.  Maybe we can
> just have a short section listing what each mechanism says, where at the moment I think we just have
> one sentence in section 3 ("IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic
> transition and Teredo rely on the use of IIDs of length 64.")
> 
> Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 13:16:54 +0100

Le 07/01/2014 12:11, Ray Hunter a écrit :
[...]
> Where exactly is the requirement that IPv6 has to use /64 prefix

Simply put, I agree with Brian that there is no one single specification
place where this could be found enshrined.

But a huge devil lies in details I dare uncover just a bit here.

First, key places like the Addressing Architecture and SLAAC RFCs
generally read as avoiding setting rigid limits on the prefix length or
the Interface ID.  For example the subnet prefix is said to be of length
'n', and the Interface ID of length '128-n'.

But even there in RFC4291 there is a quirk saying:
> For all unicast addresses, except those that start with the binary
> value 000, Interface IDs are required to be 64 bits long and to be
> constructed in Modified EUI-64 format.

(not sure what that 000 means).

Then, an IP address being of fixed length, the prefix length could be
inferred by looking at the length of the Interface ID, or other
identifiers which look like it (e.g. an anycast IID).  If that length is
rigid, one may legitimately suppose strict limits on the prefix length
as well.

The IP-over-Ethernet RFC is precise in its limit of 64bit for the
Interface ID.  The success of its deployment made it so that others copy
on it, together with that rigid limit.  Today, not only Ethernet
Interface IDs are precisely 64bit, but also WiFi, and, more surprisingly
even 802.15.4 (surprisingly because even its short address on 16bit
leads to an Interface ID on 64bits - 3rd par, sec 6 RFC 4944).  Worse,
other links which are not even documented as IP-over-foo RFCs do
implement that 64bit limit although nobody requires them to.

As for implementation enshrinment places there are many.  One easy to
spot is dmesg on modern linux upon reception of an RA containing a
prefix whose length is 65, or 63 if one so wishes.  Decimal.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 17:08:35 +0100

> the implementation)

Would these hosts use some form of address auto-configuration?

But yes, I agree with the point that this should be possible.

[...]
> shared hosting environments).

I agree that with large switches and VLANs often the links look very 
much as point to point links.

> processes that track state based on /128 IPv6 address could be attacked.

Right.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 17:19:31 +0100

Le 06/01/2014 21:51, Mark ZZZ Smith a écrit :
> One thing I think would be good to capture is a bit of the
> history/rational behind the choice of 64 IID.
>
> I became aware of that history via Christian Huitema's "IPv6: The
> New Internet Protocol (2nd Edition)" book, I think it would be good
> if that history was a bit more widely available to explain and
> justify the choice.

Hi,

I dont have the book handy, but I would be interested to learn about how
this 64bit length came to life.  I remember some discussions of an 'h'
factor.

I suppose IEEE's EUI-64 design history is related, maybe because
triggered by same fear of address space depletion (48bit identifiers);
knowing that one may see how would an EUI-128 influence in any way IPv6
addressing.

Alex

> Regards, Mark.
>> From: Brian E Carpenter <[email-masked]> To: 6man
>> <[email-masked]> Cc: Sent: Monday, 6 January 2014 9:07 AM Subject:
>> [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]
>>
>> Hi,
>>
>> -------- Original Message -------- Subject: I-D Action:
>> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 13:59:17
>> -0800 From: [email-masked] Reply-To:
>> [email-masked] To: [email-masked]
>>
>>
>> Title           : Analysis of the 64-bit Boundary in IPv6
>> Addressing Authors         : Brian Carpenter Tim Chown Fernando
>> Gont Sheng Jiang Alexandru Petrescu Andrew Yourtchenko Filename :
>> draft-carpenter-6man-why64-00.txt Pages           : 14 Date :
>> 2014-01-05
>>
>> Abstract: The IPv6 unicast addressing format includes a separation
>> between the prefix used to route packets to a subnet and the
>> interface identifier used to specify a given interface connected
>> to that subnet. Historically the interface identifier has been
>> defined as 64 bits long, leaving 64 bits for the prefix.  This
>> document discusses the reasons for this fixed boundary and the
>> issues involved in treating it as a variable boundary.
>>
>>
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Jan 2014 08:16:55 +1300

EUI-64 came first; it's used by Firewire and there was some expectation
that Firewire would become very important, or in general that EUI-64
would come to replace EUI-48.

But maybe someone who has Christian's book could send a paraphrase
of his explanation.

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 11:27:58 +0900

On Tue, Jan 7, 2014 at 8:11 PM, Ray Hunter <[email-masked]> wrote:

> "massive over sizing" of prefixes to /64: any number of untested processes
> that track state based on /128 IPv6 address could be attacked. The flip
> side of expanding privacy through address obfuscation at IID level is that
> the source space available for attacks also increases. ND cache exhaustion
> is probably just the first issue we've discovered of many that exist. This
> may have knock on operational consequences, which in the IPv4 world have
> relied on the scarcity of IPv4 address space to be able to operate
> correctly under stress scenarios. We're going to discover who has been
> swimming naked when the tide goes out. Call that FUD, or operational
> expediency, whichever you like. BCP38 has saved me on a number of occasions
> when all else has failed.
>

It's true that some implementations may have made incorrect assumptions
about IPv6 attacks based on their IPv4 knowledge. But on the other hand, a
/64 provides plentiful space, freedom from renumbering, and operational
simplicity because "you will always have enough subnet space" and "you can
pick your own IID because a /64 provides enough space for everyone".

I don't think it's a good trade-off to give up those advantages just
because of some implementations may temporarily have made insecure choices.
By the same token, we didn't design IPv4 to be partitioned into security
zones, even though I'm sure that when IPv4 rolled around, people were
shocked - and I'm sure some got burnt - by the fact that enabling IPv4 on a
machine suddenly meant that the machine was suddenly accessible from
anywhere in the world. I think it's much better to start with a flexible,
full-featured, simple architecture and them secure it.

It's not that securing it is hard to do: in first instance, make the abuse
systems just track /64s instead of tracking /128s, and problem solved. Of
course, you still have the problem that there are too many /64s to keep
track of, but there's no way around that except to stick with IPv4, or make
a new protocol that has more address space than IPv4 but less address space
than IPv6... but why would you want that?

I know that smaller subnets are consistent with IPv4. But "different from
IPv4" doesn't mean "worse than IPv4". In many cases, it means "better than
IPv4".

---

From: George Michaelson <[email-masked]>
Date: Thu, 9 Jan 2014 12:38:10 +1000

AVLs and other data structures cope fine with IPv6. Its true you have to
have a heap and pointers, rather than a statically sized array, but I think
if you want to change address architecture because you think arrays are the
only construct to process integers, you really have bigger problems.

They're bitstrings. They sort well in patricia trie

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 11:43:24 +0900

> Discussion belongs in 6man, please.

Authors,

why does the draft say that RFC 4941 says:

"[RFC4291] specifies that a unicast address is divided into n bits of
subnet prefix followed by (128-n) bits of interface identifier (IID)"

but not that it says:

"For all unicast addresses, except those that start with the binary value
000, Interface IDs are required to be 64 bits long".

Cheers,
Lorenzo

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Jan 2014 15:58:38 +1300

> 000, Interface IDs are required to be 64 bits long".

Actually that (truncated) sentence is obsoleted by draft-ietf-6man-ug which
is in the RFC queue. New version:

   "For all unicast addresses, except those that start with the binary
    value 000, Interface IDs are required to be 64 bits long. If derived
    from an IEEE MAC-layer address, they must be constructed in Modified
    EUI-64 format."

But yes, we should mention that. We reviewed a lot of RFCs and there
are probably other things we missed too.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 9 Jan 2014 12:19:30 +0900

>     value 000, Interface IDs are required to be 64 bits long. If derived

... which is exactly the sentence I cited, right? I did look at
draft-ietf-6man-ug before I blurted out, you know :-)

---

From: Ray Hunter <[email-masked]>
Date: Thu, 09 Jan 2014 17:21:10 +0100

> Lorenzo Colitti <mailto:[email-masked]>
> 9 January 2014 03:27
>
>     It may not be a widely held belief, but I remain concerned about
>     the potential for resource exhaustion for any number of processes
>     due to the "massive over sizing" of prefixes to /64: any number of
>     untested processes that track state based on /128 IPv6 address
>     could be attacked. The flip side of expanding privacy through
>     address obfuscation at IID level is that the source space
>     available for attacks also increases. ND cache exhaustion is
>     probably just the first issue we've discovered of many that exist.
>     This may have knock on operational consequences, which in the IPv4
>     world have relied on the scarcity of IPv4 address space to be able
>     to operate correctly under stress scenarios. We're going to
>     discover who has been swimming naked when the tide goes out. Call
>     that FUD, or operational expediency, whichever you like. BCP38 has
>     saved me on a number of occasions when all else has failed.
>
>
> It's true that some implementations may have made incorrect 
> assumptions about IPv6 attacks based on their IPv4 knowledge. But on 
> the other hand, a /64 provides plentiful space, freedom from 
> renumbering, and operational simplicity because "you will always have 
> enough subnet space" and "you can pick your own IID because a /64 
> provides enough space for everyone".
>
> because of some implementations may temporarily have made insecure 
> choices. By the same token, we didn't design IPv4 to be partitioned 
> into security zones, even though I'm sure that when IPv4 rolled 
> around, people were shocked - and I'm sure some got burnt - by the 
> fact that enabling IPv4 on a machine suddenly meant that the machine 
> was suddenly accessible from anywhere in the world. I think it's much 
> better to start with a flexible, full-featured, simple architecture 
> and them secure it.
>
> It's not that securing it is hard to do: in first instance, make the 
> abuse systems just track /64s instead of tracking /128s, and problem 
> solved. Of course, you still have the problem that there are too many 
> /64s to keep track of, but there's no way around that except to stick 
> with IPv4, or make a new protocol that has more address space than 
> IPv4 but less address space than IPv6... but why would you want that?
>
> I know that smaller subnets are consistent with IPv4. But "different 
> from IPv4" doesn't mean "worse than IPv4". In many cases, it means 
> "better than IPv4".
>
> ------------------------------------------------------------------------
Most organisations I know have way less than 100K hosts globally, and 
typically 10's or 100s of hosts per LAN.

We seem to agree that people can't track at /64 because 2^64 is too big 
to track.

Why then would we suggest that people track at /64 level when you 
already admit there's equally too many /64's to track (also 2^64)?

The point is that people *could* trivially track and filter at /128 
within an enterprise *if* we give network infra people the ability to 
control/register which /128(s) the end host uses.

Ideally, that ability to control/register active /128's should not rely 
on cooperation of L2 switches or other LAN functionality that requires 
purchasing new switches, or constant MIB scanning.

I think that's a valid problem statement, and assigning >>/64 
(purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or 
static addressing) is one way to address that problem.

Is there anything better?

-- 
Regards,
RayH

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 17:25:15 +0100

Le 09/01/2014 04:19, Lorenzo Colitti a écrit :
> On Thu, Jan 9, 2014 at 11:58 AM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
>

Let me try a clarification.  If it dares too far, excuses.

RFC4291 Addr Arch document says prefixes are of length n and IIDs of 
length 128-n.  Further it says that IIDs are required to be 64bit long.

A new document now in RFC Editor queue says that IIDs must be 64bit long 
and, additionally, when derived from a 48bit MAC address they must be 
constructed as 'Modified EUI-64'. (this is part of the u/g discussion).

This is not the end of the story, but could be a path to it.  Let me say 
why.

One agrees that addresses are n/128-n.  Then one makes them 64.  Then 
make them 64-but.  And further one may try to interpret them as along 
these hypothetical lines:
>     value 000, Interface IDs are required to be 128-n bits long. If derived

This is just speculation on my part.

Alex

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Jan 2014 16:32:16 +0000

On 9 Jan 2014, at 16:21, Ray Hunter <[email-masked]> wrote:

>> It's true that some implementations may have made incorrect assumptions about IPv6 attacks based on their IPv4 knowledge. But on the other hand, a /64 provides plentiful space, freedom from renumbering, and operational simplicity because "you will always have enough subnet space" and "you can pick your own IID because a /64 provides enough space for everyone".
>> 
>> I don't think it's a good trade-off to give up those advantages just because of some implementations may temporarily have made insecure choices. By the same token, we didn't design IPv4 to be partitioned into security zones, even though I'm sure that when IPv4 rolled around, people were shocked - and I'm sure some got burnt - by the fact that enabling IPv4 on a machine suddenly meant that the machine was suddenly accessible from anywhere in the world. I think it's much better to start with a flexible, full-featured, simple architecture and them secure it.
>> 
>> It's not that securing it is hard to do: in first instance, make the abuse systems just track /64s instead of tracking /128s, and problem solved. Of course, you still have the problem that there are too many /64s to keep track of, but there's no way around that except to stick with IPv4, or make a new protocol that has more address space than IPv4 but less address space than IPv6... but why would you want that?
>> 
>> I know that smaller subnets are consistent with IPv4. But "different from IPv4" doesn't mean "worse than IPv4". In many cases, it means "better than IPv4".
>> 
> Most organisations I know have way less than 100K hosts globally, and typically 10's or 100s of hosts per LAN.
> 
> We seem to agree that people can't track at /64 because 2^64 is too big to track.
> 
> Why then would we suggest that people track at /64 level when you already admit there's equally too many /64's to track (also 2^64)?
> 
> The point is that people *could* trivially track and filter at /128 within an enterprise *if* we give network infra people the ability to control/register which /128(s) the end host uses.
> 
> Ideally, that ability to control/register active /128's should not rely on cooperation of L2 switches or other LAN functionality that requires purchasing new switches, or constant MIB scanning.
> 
> I think that's a valid problem statement, and assigning >>/64 (purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or static addressing) is one way to address that problem.

I;m not sure you're defining what your problem is fully enough here.

What's wrong with polling network devices to maintain a database of IP/MAC/port bindings?  Some reasonably sized campuses with IPv6 deployed do just that, on the assumption devices can effectively pick their own addresses and/or change them over time.

Tim

---

From: Ray Hunter <[email-masked]>
Date: Thu, 09 Jan 2014 18:18:33 +0100

> Tim Chown <mailto:[email-masked]>
> 9 January 2014 17:32
>
> What's wrong with polling network devices to maintain a database of 
> IP/MAC/port bindings? Some reasonably sized campuses with IPv6 
> deployed do just that, on the assumption devices can effectively pick 
> their own addresses and/or change them over time.
>
> Tim

I'd also probably consider that on a campus, which is geographically 
limited, there's no latency, network devices are uniform, there's a 
single management vendor, SNMP access is allowed, and bandwidth is free.

DHCP (which is effectively a form of event-triggered central 
registration) works pretty well today. Two people can support all global 
IPAM, DHCP, and DNS for 100K users in 50 countries. All you need is the 
lowest common denominator of a DHCP proxy on any LAN equipment pointing 
at your regional servers, and a DHCP client on end user devices, which 
is basically universally supported. And you can lever that information 
up in all sorts of ways. DHCPv6 would not be cost impacting (part of 
licensing on existing kit). Anything else would be. You're not going to 
be able to get any less than 2 support people for this sort of 
enterprise critical infra. Off topic for this ID, but just saying.

The bottom line is that sparse addressing in IPv6, as implemented today, 
also has a down side for enterprise operations; but perhaps that 
discussion should be held in v6ops.

-- 
Regards,
RayH

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Jan 2014 17:31:22 +0000

On 9 Jan 2014, at 17:18, Ray Hunter <[email-masked]> wrote:

> I'd also probably consider that on a campus, which is geographically limited, there's no latency, network devices are uniform, there's a single management vendor, SNMP access is allowed, and bandwidth is free.
> 
> DHCP (which is effectively a form of event-triggered central registration) works pretty well today. Two people can support all global IPAM, DHCP, and DNS for 100K users in 50 countries. All you need is the lowest common denominator of a DHCP proxy on any LAN equipment pointing at your regional servers, and a DHCP client on end user devices, which is basically universally supported. And you can lever that information up in all sorts of ways. DHCPv6 would not be cost impacting (part of licensing on existing kit). Anything else would be. You're not going to be able to get any less than 2 support people for this sort of enterprise critical infra. Off topic for this ID, but just saying.

Fair comment, but for a campus style network, I'd argue for the polling approach, and it works well (enough).

There's a distinction though between controlling addresses and being able to observe all addresses that are in use.

> The bottom line is that sparse addressing in IPv6, as implemented today, also has a down side for enterprise operations; but perhaps that discussion should be held in v6ops.

Well, I think it's relevant to this draft.

I'm not sure it's really down to the sparse addressing per se, rather that there is enough address space in a subnet for there to be a mechanism for hosts to pick multiple addresses to use over time.

Tim

---

From: Emmanuel Thierry <[email-masked]>
Date: Thu, 9 Jan 2014 18:51:19 +0100

Hello,

(first message on these lists, hope it is accurate)

I'm generally thinking that the /64 limit helps to structure the address space from the receiver point of view. Let's say i'm running a mail server which tries to reduce spam by temporarily blacklisting some senders. if i'm facing spammers who use their IPv6 address space in a smart way, they will just have to generate RFC 4941 addresses to exhaust a firewall memory. The pragmatic way to face such attacks is to blacklist the whole /64, never a unique /128.

I don't know if it is to be considered as a best practice, but for these reasons, as a receiver, i personally consider a /64 to be assigned to a unique link, or at least a network managed by a unique network administrator. Enforcing this limit in protocol standards strengthen this assumption. This might be an additional argument for the "please keep /64 for unique links".

As a consequence, subdivide a /64 into several prefixes in order to assign it on several networks might create a risk for devices on one network to be blacklisted by actions performed by some devices on another network, in case the whole /64 have been blacklist by a "pragmatic" receiver. 

Best regards
Emmanuel Thierry

---

From: Ray Hunter <[email-masked]>
Date: Thu, 09 Jan 2014 19:39:58 +0100

> 9 January 2014 18:31
> On 9 Jan 2014, at 17:18, Ray Hunter<[email-masked]>  wrote:
>
>>> Tim Chown<mailto:[email-masked]>
>>> 9 January 2014 17:32
>>>
Agreed. Many scenarios I have in mind are about knowing all addresses in 
use, and who is using them. Not necessarily limiting them.
> I'm not sure it's really down to the sparse addressing per se, rather that there is enough address space in a subnet for there to be a mechanism for hosts to pick multiple addresses to use over tim…
My point of view is that there's a trade off to be made between "too few 
and too many" when talking about sparse address allocation, and that the 
current fixed /64 boundary allows "too many" IIDs/IPv6 addresses for 
many operational scenarios. So many in fact that it's a potential 
liability. Either that or we need a mechanism that more reliably tracks 
and registers addresses actually in use on a semi-trusted environment, 
so that the actual /128's in use are known (centrally) e.g. for 
improving/extending source address validation and anti-spoofing, 
helpdesk calls, log correlation, QoS tracking etc.

As an example, how many implementations of QoS mechanisms like WFQ do 
you know today that protect their resources used for counting active 
flows on a /48 and /64 boundary? And how many just track session use per 
/128? Or have no limit at all on allowable active sessions per 
address/prefix?

So how many implementations are vulnerable today to flow table size 
exhaustion that could have a global service impact by an attack from a 
single compromised host that can spoof source addresses from an entire 
/64 or /48?

-- 
Regards,
RayH

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Jan 2014 14:01:32 +0900

On Fri, Jan 10, 2014 at 1:21 AM, Ray Hunter <[email-masked]> wrote:

> The point is that people *could* trivially track and filter at /128 within
>> an enterprise *if* we give network infra people the ability to
> Ideally, that ability to control/register active /128's should not rely on
> cooperation of L2 switches or other LAN functionality that requires
> (purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or static
> addressing) is one way to address that problem.
>

In your network you are free to assign addresses exclusively using DHCPv6.

*However* - if you are doing this for the purpose of tracking, that only
makes any sense at all if the current switches you have (since you've
already said you're not going to buy new ones) can snoop DHCPv6 requests
for address assignments enforce IPv6-to-MAC address mappings.

Do they?

Because if they don't, disabling SLAAC gives you no security at all,
because malicious hosts on your network will still be free to create and
use arbitrary IPv6 addresses, which you will not be able to track. In fact,
this gives you the same level of security as you could by disabling privacy
addresses and using autoconf - malicious hosts can still do what they want,
and for well-behaved hosts, instead of having the MAC address in the IPv6
address, you now have to go and get it from the DHCPv6 server logs.
Lose/lose.

Or - as Tim points out, SNMP scraping will do this securely for you today,
and vendors are already building better and more scalable address
registration notification features (syslog, etc.) into switches.

And if you're not doing this for the purpose of tracking, then why are you
doing it? Is it just because it's what you do in IPv4? If so, then sorry,
that's not a valid technical argument.

---

From: Ray Hunter <[email-masked]>
Date: Fri, 10 Jan 2014 09:10:57 +0100

> 10 January 2014 06:01
>     Ideally, that ability to control/register active /128's should not
>     rely on cooperation of L2 switches or other LAN functionality that
>     requires purchasing new switches, or constant MIB scanning.
>
> *However* - if you are doing this for the purpose of tracking, that 
> only makes any sense at all if the current switches you have (since 
> you've already said you're not going to buy new ones) can snoop DHCPv6 
> requests for address assignments enforce IPv6-to-MAC address mappings.
>
> Do they?
>
You are apparently imposing a model which assumes a single management 
vendor is responsible right up until the edge of the network at port level.

That is rarely true in any enterprise I've worked on. They are not my 
customer's switches. They don't manage them at all. They subcontract 
that to multiple parties.

In the case of multiple management providers, people need to protect 
their own services from the failings of others.

If a site is under autonomous management (e.g. trusted 3rd party) then 
they may be assigned a /48 in your model.

OK they're responsible for their own /48 and they can suffer the 
consequences of poor management of devices in their site.

But problems in their /48 with a rogue node assigning zillions of 
addresses and creating zillions of sessions should not spill over into 
the rest of the network managed by others.

WFQ QoS (and many other processes which requires tracking of individual 
sessions or IP addresses) running in another vendor's network should not 
fail because of a single node in a single 3rd party network swamps an 
address/session table.

I think that people need some way of limiting the number of active 
/128's at the network-network interface. It would be even better if we 
could either register or control to the /128 and identify those to a 
host or user.

One way of doing that is to agree with trusted 3rd party sites (which 
generally only have a tiny number of hosts allowed to communicate across 
the boundary) to only assign an agreed /120 out of their /48 allocation, 
which requires prefix lengths >>64 (this ID) or at least the ability to 
apply ACL filters >> /64.

Another way is source address validation at the edge, with limits 
assigned on a first come first served basis.

Another is to ban all processes that need to track an individual IPv6 
address.

Another is to contract that the site themselves are responsible for 
limiting resource depletion attacks, but I'd still want some protection 
on the receiving side.

I'd rather be tracking the 100K nodes that I know should be on the 
network out of a potential 24*2^16 addresses, rather than trying to stop 
a 100 zillion anonymous nodes who I can't even identify so that the 100K 
can work.

DHCP has been successfully implemented in multi-vendor environments. The 
local LAN manager/outsourcer only has to configure up the LAN interface 
either the correct IP address and subnet mask, and point a DHCP proxy at 
a regional server (managed by someone else) They can make changes within 
a site autonomously without bothering the central team, and it all just 
works.

DHCPv6 potentially can provide a form of centralised registration (and 
then be linked to admission control, or at least give cooperating end 
nodes a higher QoS than unidentified end nodes) and support a similar 
operations model.
You could also allocate a /64, configure a DHCPv6 address pool to assign 
addresses from a range >>64 and apply and ACL, or assign and allocate 
 >>64 prefix length (which seems easier).

Because if they don't, disabling SLAAC gives you no security at all, 
because malicious hosts on your network will still be free to create and 
use arbitrary IPv6 addresses, which you will not be able to track. In 
fact, this gives you the same level of security as you could by 
disabling privacy addresses and using autoconf - malicious hosts can 
still do what they want, and for well-behaved hosts, instead of having 
the MAC address in the IPv6 address, you now have to go and get it from 
the DHCPv6 server logs. Lose/lose.

That is also a problem. The assumption seems to be that there has been 
of smart nodes and a dumb network that does not run any processes 
requiring differential services or that tracking of individual end hosts 
is universally bad.

But I thought we'd established that we're not exclusively talking about 
forcing use of particular addresses for all machines, rather 
establishing which nodes are genuinely active, and attempting to 
establish centrally what machine they are being used by.
>
> Or - as Tim points out, SNMP scraping will do this securely for you 
> today, and vendors are already building better and more scalable 
> address registration notification features (syslog, etc.) into switches.
Not everyone allows SNMP access from other management vendors in a multi 
vendor environment. Not everyone feeds syslog to other management vendors.
Again, you are imposing an alien operations model. It imposes polling, 
It imposes inter-vendor cooperation and access to all remote devices via 
a management protocol.
Every time a switch on any one of 1000 sites changes, you're going to 
have to update your central poller. A central registration model avoids 
that overhead.
> And if you're not doing this for the purpose of tracking, then why are 
> you doing it? Is it just because it's what you do in IPv4? If so, then 
> sorry, that's not a valid technical argument.
At the risk of repeeating myself: helpdesk call correlation, problem 
correlation, log correlation, ability to track to /128 (for future 
filtering or tracking or resource protection of processes and devices 
within the network that rely on databases or caches keyed by IP address)

In IPv4, this protection happens automatically due to address scarcity, 
without doing anything else.

IPv6 /64 breaks address scarcity.

-- 
Regards,
RayH

---

From: Tim Chown <[email-masked]>
Date: Fri, 10 Jan 2014 08:37:53 +0000

On 10 Jan 2014, at 08:10, Ray Hunter <[email-masked]> wrote:

>> Or - as Tim points out, SNMP scraping will do this securely for you today, and vendors are already building better and more scalable address registration notification features (syslog, etc.) into switches.
> Not everyone allows SNMP access from other management vendors in a multi vendor environment. Not everyone feeds syslog to other management vendors.
> Again, you are imposing an alien operations model. It imposes polling, It imposes inter-vendor cooperation and access to all remote devices via a management protocol.

Actually, no. It's a choice. We saw the choice of trying to lock down all address assignment for IPv6, or instead to accept that any device can pick any address and put measures in place to monitor/track which addresses are used where (should we need to trace something back).  We chose the latter approach.  If you want to take the lock-down path, that's your choice.

> Every time a switch on any one of 1000 sites changes, you're going to have to update your central poller. A central registration model avoids that overhead.

Well, yes, but there would be some provisioning for that device and you just need to make the polling configuration part of that.  It's usually as simple as an address to poll. In our case (as you guess :) most of our equipment is one vendor.

The SNMP polling approach has advantages too.  There's a lot of very useful information you glean from that, that can be very beneficial in aspects of network management other than address accountability.

We also make quite heavy use of 802.1X btw, but then many campuses do so today thanks to eduroam.

>> And if you're not doing this for the purpose of tracking, then why are you doing it? Is it just because it's what you do in IPv4? If so, then sorry, that's not a valid technical argument.
> At the risk of repeeating myself: helpdesk call correlation, problem correlation, log correlation, ability to track to /128 (for future filtering or tracking or resource protection of processes and devices within the network that rely on databases or caches keyed by IP address)
> 
> In IPv4, this protection happens automatically due to address scarcity, without doing anything else.
> 

I think many sites will see there are also positive sides to this, and embrace it rather than trying to lock everything down.  But it's a choice.

Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 09:53:50 +0100

Hello,

Thanks for the post.

I could understand the need to spam block an entire /64 instead (a
single line in a configuration file) rathern than 2^64 lines each
telling an address in that file.

Yes, this is relevant when writing other firewalling rules as well.

In this sense it is good to have an 'overall' number - like a /64 - to
designate one particular link and subnet.

And one may like to use other such overall numbers such as a /65 or a
/63 to designate these links.

And yes, the privacy extensions RFC4941 makes that attacker may use that
overall number /64 to generate addresses, and defender may need to use
same number /64 to comfortably protect against it.  A smarter attacker
would use a /63 and a smarter defender too.

Alex

Le 09/01/2014 18:51, Emmanuel Thierry a écrit :
> I'm generally thinking that the /64 limit helps to structure the
> address space from the receiver point of view. Let's say i'm running
> a mail server which tries to reduce spam by temporarily blacklisting
> some senders. if i'm facing spammers who use their IPv6 address
> space in a smart way, they will just have to generate RFC 4941
> addresses to exhaust a firewall memory. The pragmatic way to face
> such attacks is to blacklist the whole /64, never a unique /128.
>
> I don't know if it is to be considered as a best practice, but for
> these reasons, as a receiver, i personally consider a /64 to be
> assigned to a unique link, or at least a network managed by a unique
> network administrator. Enforcing this limit in protocol standards
> strengthen this assumption. This might be an additional argument for
> the "please keep /64 for unique links".
>
> As a consequence, subdivide a /64 into several prefixes in order to
> assign it on several networks might create a risk for devices on one
> network to be blacklisted by actions performed by some devices on
> another network, in case the whole /64 have been blacklist by a
> "pragmatic" receiver.
>
> Best regards Emmanuel Thierry
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Jan 2014 17:59:38 +0900

> IPv6 /64 breaks address scarcity.

Wait, maybe I see your position now. You're thinking of a transit network,
and you want to limit the number of addresses assigned at the edge so the
middleboxes can cope?

But I still don't understand. In most cases, in such a transit network you
can't do individual machine tracking already because machines are behind
NATs. So why is it so important to track every machine in IPv6?

Also, I don't understand why you wouldn't use hierarchical addressing and
delegation - which is what you might naturally do even in IPv4 - and track
ranges instead of individual addresses.

Perhaps I don't understand the use case. Can you say more about what sort
of networks would need this functionality?

---

From: Ray Hunter <[email-masked]>
Date: Fri, 10 Jan 2014 11:50:09 +0100

> 10 January 2014 09:59
> Wait, maybe I see your position now. You're thinking of a transit 
> network, and you want to limit the number of addresses assigned at the 
> edge so the middleboxes can cope?

Not just middleboxes. Any process that tracks anything on the basis of 
an IP address.

As a simple example, think of a mail server. Mail servers get abused. 
They can generally handle themselves.

To mitigate resource depletion, postfix runs an "anvil" process in 
memory. It's a light weight process that simply tracks the number of 
recent connections in memory from each source IPv4 /32 for a short period.
When an individual IPv4 source address sends "too many requests too 
quickly", postfix does not even open the TCP session with this client.
The main postfix process daemon can then continue to serve other 
well-behaved nodes whilst the rogue node is "shut out".

With IPv6 /64, and massively oversized allocations, that defence 
approach is invalidated, because the anvil process itself becomes a 
weakness, as it cannot track to /128.
You could possibly track at /64, although even that might be too big to 
handle in memory, with the consequence that one rogue node can create 
false positives, and take down a whole LAN or site.

How do you know that the remote rogue site or rogue host is a single /64 
and not a /52 or /56 or /48?
Do you track all of the above simultaneously? That has potential for 
even bigger false positives.

In general, if you want to provide a third party access to your mail 
server or other server for information exchange, you probably want some 
way of throttling access at the Network Network Interface (NNI) from 
individual rogue nodes without cutting off well-behaved nodes.

Or alternatively, providing preferential access to well-behaved nodes, 
with WFQ-like solutions.

Either way you need to be able to differentiate and track node behaviour 
at a fairly granular level.

Address scarcity has some upside too, in that it limits attack source 
surface, and allows tracking at node level, and I do not feel that has 
been sufficiently acknowledged.

Registration of "well-behaved nodes" could be another potential 
approach. Perhaps leveraging AD forests.
>
> But I still don't understand. In most cases, in such a transit network 
> you can't do individual machine tracking already because machines are 
> behind NATs. So why is it so important to track every machine in IPv6?
>
In the areas I work in, they are inter-enterprise connections to trusted 
3rd parties.
We try to avoid NAT wherever possible (isn't that the right thing to do? ;)
We even use registered addresses on the inside and outside.

Security people want as tight a filter as possible. It cannot be the 
case that a technical problem in a trusted third party spills over into 
your enterprise, even if this is protected contractually.

It's a real nice have to have some upper limit of possible source 
addresses or sessions for scaling of logs/ scanners/ network intrusion 
detection systems etc.
Otherwise the middleboxes themselves can fall over.

It's would also be nice to know who these people are (admittedly we only 
"know" that today due to some level of trust linked to address 
allocation schemes e.g. this person is assigned this IPv4address in DHCP 
or via their SSL VPN connection login). Some of that could be translated 
into IPv6 with prefix lengths >>64e.g.: an SSL VPN with a /127 = a person.

IPv4 and IPv6 is probably not the layer where this identity link should 
be established, but it's generally all we have today.
> Also, I don't understand why you wouldn't use hierarchical addressing 
> and delegation - which is what you might naturally do even in IPv4 - 
> and track ranges instead of individual addresses.
In an enterprise NNI, or private cloud service, the source and 
destination ranges would be huge, and the complete list of individual 
allocations are generally unknown to the other party.

The customer might have a /32. The private cloud provider might have a 
/32. There is generally no hierarchy. These are peer networks of equals.
But even then, there's probably only a few tens to thousands machines on 
each side of the NNI that need to communicate.

We generally limit the number of potential source addresses and sessions 
today by filtering to /32 or /24 or /16 at the NNI plus only allowing 
certain port numbers.

That's massively smaller than granting access to a single IPv6 LAN of 
/64 for a single port.

For example, a single source IPv4 /32 with access to 1 port on 4 
destination IPv4 servers is never ever going to be able to saturate a 
flow-based WFQ session table, even if it is compromised. This source 
machine can only ever create 4 flows simply because of the ACL at the NNI.

A single source machine (that has been compromised ) running IPv6 
connected to a /64 using SLAAC + temporary addresses  (and which 
connects to 1 port on 1 server connected to /64 with SLAAC) could easily 
saturate a flow-based WFQ table, causing service degradation to other 
well-behaved nodes, simply because the ACL is so much bigger, and the 
compromised machine can create so many more rogue flows.
>
> Perhaps I don't understand the use case. Can you say more about what 
> sort of networks would need this functionality?
>
Interconnections between enterprises, or within enterprises where 
different sites are managed by different parties, and avoiding cross 
contamination of resource depletion attacks sourced from single rogue 
nodes or sites.
Even an ACL for a single /64 for a single port is massively bigger than 
the biggest access we grant today. Which probably leaves static 
addressing as the only option. Because alternative defence mechanisms 
simply aren't in place yet.

-- 
Regards,
RayH

---

From: Emmanuel Thierry <[email-masked]>
Date: Fri, 10 Jan 2014 11:57:00 +0100

Hello,

Thanks for your answer.

> would use a /63 and a smarter defender too.

Definitely. However, as an attacker, having a smaller prefix than a IPv6 /64 to exploit for your attack could correspond in IPv4 to use a smaller prefix than /32.
I mean that as a defender, i would use against an attacker who smartly uses its /63 or smaller, the same techniques than an attacker who have access to an IPv4 /31 or smaller: blacklist sequentially all IPv6 /64 that this attacker is using. So anyway, a /64 boundary would at least help to leverage the problem.

This could also be a good hint to network operators or hosters. Some virtual machine providers (for instance) divide their /64 into smaller prefixes (i saw /96), which may imply that a bad behavior from one of their clients might influence other servers. I think there should be a clear mention of the consequences it may have. Such a mention may help to promote best practices (TODO: define best practices).

Best regards
Emmanuel Thierry

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 10 Jan 2014 22:58:17 +0900

On Fri, Jan 10, 2014 at 7:50 PM, Ray Hunter <[email-masked]> wrote:
> With IPv6 /64, and massively oversized allocations, that defence approach
> is invalidated, because the anvil process itself becomes a weakness, as it
> cannot track to /128.
> handle in memory, with the consequence that one rogue node can create false
> positives, and take down a whole LAN or site.
>

But Postfix mail servers are exposed to the Internet. And the Internet
already connects tens of millions of users that have /56 prefixes at their
beck and call to mount an attack. Obviously, the naive approach of tracking
to /128 is not going to scale. But neither does the naive approach of
storing BGP tables in linked lists. Fortunately, router implementations use
patricia tries and hash tables, and equivalently, fortunately it's possible
to do better than to track at the /128 level.

> Do you track all of the above simultaneously? That has potential for even
> bigger false positives.
>

Three minutes of thought suggest that you could have separate /64, /56 and
/48 tables (or whatever) and when a certain threshold of entries in one
table match the entries in the table one level shorter, delete them and
block the covering prefix at the shorter prefix level. Thinking about it
for three hours instead of three minutes will probably produce several more
sophisticated ideas - one example is looking for evenly-spaced spikes in
prefix usage patterns in historical log data to detect ISP assigned prefix
sizes in particular blocks, and then track that region of the IPv6 space at
that block size.

> server or other server for information exchange, you probably want some way
> of throttling access at the Network Network Interface (NNI) from individual
> rogue nodes without cutting off well-behaved nodes.
>

Why individual rogue nodes? In most networks (maybe yours is an exception;
but in general, anything exposed to residential users), you can't see the
nodes. You can see NAT pool IPs. So we're already tracking by the block,
even in IPv4.

> surface, and allows tracking at node level, and I do not feel that has been
> sufficiently acknowledged.
>

If address scarcity is what you want, there's a well-supported,
ubiquitously deployed protocol you can use: IPv4. Unfortunately, its main
problem is... address scarcity. We're trying to fix that problem. We can't
fix it by creating more scarcity.

> "know" that today due to some level of trust linked to address allocation
> schemes e.g. this person is assigned this IPv4address in DHCP or via their
> SSL VPN connection login).

Why can't you associate an SSLVPN connection login with a /64? It's still
one login.

> Some of that could be translated into IPv6 with prefix lengths >>64e.g.:
> an SSL VPN with a /127 = a person.
>

Why a /127? Why not a /64? It's the same number of state entries - one per
login. And a /127 (or even a /128) is not one machine. It could be one
machine, or it could be a distributed cluster of machines running a
transparent TCP proxy for 100000 clients. For example:

star.c10r.facebook.com has IPv6 address 2a03:2880:f00f:300:face:b00c:0:1

You don't think that's one machine, right?

> machine can only ever create 4 flows simply because of the ACL at the NNI.

But WFQ scales in terms of the buffer size (i.e., the total length of the
queue), not in the number of flows, right? If what you're queueing is
packets, then the queue is not unbounded and there is no scaling issue.

> the biggest access we grant today. Which probably leaves static addressing
> as the only option. Because alternative defence mechanisms simply aren't in
> place yet.
>

In this case, what you want DHCP for is not tracking - it's predictability.
You want to assign a given client an address that will pass through the
security pinhole.

There's nothing stopping you from doing this even if the client is on a /64
subnet with SLAAC turned on - just assign addresses via DHCPv6 or
statically, configure the firewall to pass one /128, and configure the
application to use the "magic" address you gave it. You don't need to
create scarcity for that to work; it would work perfectly well if the host
had a SLAAC address and 5 temporary addresses for Internet access, for
example.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Jan 2014 11:27:24 +1300

> But problems in their /48 with a rogue node assigning zillions of addresses and creating zillions of sessions should not spill over into the rest of the network managed by others. 

Who says that is a rogue node? It sounds like perfectly legitimate
behaviour for a virtual machine environment that is designed to
virtualise at layer 3. If you want those VM addresses to be
unguessable for an off-path attacker, you might well spread them
sparsely across a /64.

Anyway -- I am not seeing much in this thread that suggests text changes
in the -why64 draft (which is intended to be factual). I take Ray's
original point that there *might* be other risks than ND exhaustion,
and we'll add that to the next version.

Regards
   Brian

---

From: Ray Hunter <[email-masked]>
Date: Sat, 11 Jan 2014 15:26:14 +0100

> Brian E Carpenter <mailto:[email-masked]>
> 10 January 2014 23:27
Agreed.

I would also like to reiterate a basic requirement from network and 
system operators, and propose the following text for -why64.

/
There is a desire by many network operators to
1) know and audit which nodes are active on a network (perhaps by 
carrying out exhaustive scanning of address space that is allowed to 
communicate off link)
2) be able to limit the total number of active addresses and sessions 
that can be sourced from a particular host, LAN or site, in order to 
prevent potential resource depletion attacks or other problems spreading 
beyond a certain scope of control.

One way of limiting the scan space, or limiting the number of possible 
source addresses and sessions from a LAN, is to increase the prefix 
length >> 64.
This may currently break many widely-deployed solutions, such as SLAAC.

There are alternatives, which present a different set of trade offs e.g. 
with respect to the right of privacy of the end user versus the rights 
of the operator to control and protect their network.
/

Whether you think the solution of extending prefix length >>64 is good 
or not is a separate debate.
IMHO Technically it should be possible. CIDR has NOT been deprecated.

I think imposing a hard limit of /64 is harmful, as it limits operators 
choice of operations model and protocols
e.g. flow-based WFQ becomes vulnerable to trivial attacks from a single 
node, whereas there's nothing fundamentally wrong with flow-based WFQ 
technology per se, or indeed other mechanisms that require tracking 
state to /128.
e..g exhaustive network scanning to check for vulnerable open ports on 
unpatched machines becomes impractical, whereas there's nothing 
fundamentally wrong with the concept in an enterprise environment.

Lorenzo and I clearly disagree on this point, but I see no value in 
continuing the debate on list wrt this draft.
it took long enough to get to the current status on allowing use of /127 
instead of /64 for point to point links (3627, 6164, 6547)

-- 
Regards,
RayH

---

From: Tim Chown <[email-masked]>
Date: Sat, 11 Jan 2014 17:29:44 +0000

Hi,

On 11 Jan 2014, at 14:26, Ray Hunter <[email-masked]> wrote:

> I would also like to reiterate a basic requirement from network and system operators, and propose the following text for -why64.
> 
> 
> /

Many, or some?

> 1) know and audit which nodes are active on a network (perhaps by carrying out exhaustive scanning of address space that is allowed to communicate off link)

Or polling the network devices via SNMP or similar.  Exhaustive scanning of v6 space…no.

> 2) be able to limit the total number of active addresses and sessions that can be sourced from a particular host, LAN or site, in order to prevent potential resource depletion attacks or other problems spreading beyond a certain scope of control.

Documenting some examples of this would be useful.  ND cache is one, which I think is already mentioned.

> One way of limiting the scan space, or limiting the number of possible source addresses and sessions from a LAN, is to increase the prefix length >> 64.

Which is what makes this relevant to ‘why64’.

> This may currently break many widely-deployed solutions, such as SLAAC.

Well, ‘This will cause significant issues for the operation of the network, as described elsewhere in this document’

> There are alternatives, which present a different set of trade offs e.g. with respect to the right of privacy of the end user versus the rights of the operator to control and protect their network.
> /

Those alternatives are more likely to be viable in a tightly managed environment, where there is administrative control of all devices, e.g. so provacy addresses can be disabled by policy.

Tim

> 
> Whether you think the solution of extending prefix length >>64 is good or not is a separate debate.
> I think imposing a hard limit of /64 is harmful, as it limits operators choice of operations model and protocols
> e.g. flow-based WFQ becomes vulnerable to trivial attacks from a single node, whereas there's nothing fundamentally wrong with flow-based WFQ technology per se, or indeed other mechanisms that require tracking state to /128.
> e..g exhaustive network scanning to check for vulnerable open ports on unpatched machines becomes impractical, whereas there's nothing fundamentally wrong with the concept in an enterprise environment.
> 
> Lorenzo and I clearly disagree on this point, but I see no value in continuing the debate on list wrt this draft.
> it took long enough to get to the current status on allowing use of /127 instead of /64 for point to point links (3627, 6164, 6547)
> 
> -- 
> Regards,
> RayH
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Jan 2014 16:52:09 +0100

Hello,

Just out of curiosity... below...

Le 10/01/2014 11:57, Emmanuel Thierry a écrit :
>> In this sense it is good to have an 'overall' number - like a /64
>> - to designate one particular link and subnet.
>>
>> And one may like to use other such overall numbers such as a /65
>> or a /63 to designate these links.
>>
>> And yes, the privacy extensions RFC4941 makes that attacker may
>> use that overall number /64 to generate addresses, and defender
>> may need to use same number /64 to comfortably protect against it.
>> A smarter attacker would use a /63 and a smarter defender too.
>
> Definitely. However, as an attacker, having a smaller prefix than a
> IPv6 /64 to exploit for your attack could correspond in IPv4 to use
> a smaller prefix than /32. I mean that as a defender, i would use
> against an attacker who smartly uses its /63 or smaller, the same
> techniques than an attacker who have access to an IPv4 /31 or
> smaller: blacklist sequentially all IPv6 /64 that this attacker is
> using. So anyway, a /64 boundary would at least help to leverage the
> problem.
>
> This could also be a good hint to network operators or hosters. Some
> virtual machine providers (for instance) divide their /64 into
> smaller prefixes (i saw /96),

When a virtual machine uses a /96 instead of a /64, is that prefix
present in an RA?

And, is there some address auto-configuration involved?  (wondering
about how is the Interface ID formed, because with Ethernet it must be
64bit long).

(for example, in some non-Ethernet links - like IP/USB, or some
IP/cellular - there are some particular non-documented mechanisms to
form Interface IDs; but these are still 64bit length, never 22bit)

Alex

  which may imply that a bad behavior
> from one of their clients might influence other servers. I think
> there should be a clear mention of the consequences it may have.
> Such a mention may help to promote best practices (TODO: define best
> practices).
>
>>>  address space from the receiver point of view. Let's say i'm
>>> running a mail server which tries to reduce spam by temporarily
>>> blacklisting some senders. if i'm facing spammers who use their
>>> IPv6 address space in a smart way, they will just have to
>>> generate RFC 4941 addresses to exhaust a firewall memory. The
>>> pragmatic way to face such attacks is to blacklist the whole
>>> /64, never a unique /128.
>>>
>>> I don't know if it is to be considered as a best practice, but
>>> for these reasons, as a receiver, i personally consider a /64 to
>>> be assigned to a unique link, or at least a network managed by a
>>> unique network administrator. Enforcing this limit in protocol
>>> standards strengthen this assumption. This might be an
>>> additional argument for the "please keep /64 for unique links".
>>>
>>> As a consequence, subdivide a /64 into several prefixes in order
>>> to assign it on several networks might create a risk for devices
>>> on one network to be blacklisted by actions performed by some
>>> devices on another network, in case the whole /64 have been
>>> blacklist by a "pragmatic" receiver.
>>>
>>>> A group of us put this together following a discussion some
>>>> weeks ago on the v6ops list about the 64-bit boundary in IPv6
>>>> addresses. Discussion belongs in 6man, please.
>>>>
>>>> This draft is incomplete but we'd welcome input. Let me
>>>> underline an important comment in the introduction:
>>>>
>>>> _The purpose of this document is to analyse the issues around
>>>> this question.  We make no proposal for change, but we do
>>>> analyse the possible effects of a change._
>>>>
>>>>
>>>> Brian + co-authors
>>>>
>>>> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014
>>>> 13:59:17 -0800 From: [email-masked] Reply-To:
>>>> Gont Sheng Jiang Alexandru Petrescu Andrew Yourtchenko Filename
>>>> : draft-carpenter-6man-why64-00.txt Pages           : 14 Date :
>>>> 2014-01-05
>>>>
>>>> Abstract: The IPv6 unicast addressing format includes a
>>>> separation between the prefix used to route packets to a
>>>> subnet and the interface identifier used to specify a given
>>>> interface connected to that subnet. Historically the interface
>>>> identifier has been defined as 64 bits long, leaving 64 bits
>>>> for the prefix.  This document discusses the reasons for this
>>>> fixed boundary and the issues involved in treating it as a
>>>> variable boundary.
>>>>
>>>>

---

From: Emmanuel Thierry <[email-masked]>
Date: Wed, 15 Jan 2014 17:40:00 +0100

Hello,

> When a virtual machine uses a /96 instead of a /64, is that prefix

About the hoster i think about, i didn't subscribe to their service (i let you guess why ! ;)).
However, their docs mention two major points:
* How to calculate the IPv6:  2001:db8:1:XXX:XXX:XXX:XXX:YYYY/96 where XXX:XXX:XXX:XXX is the IPv4 address (!!!) and YYYY is a number between 0000 and FFFF
* How to configure the IPv6: (...) in /etc/sysconfig/network add "IPV6_AUTOCONF=no" (...)

So there is likely no RA on their network. It is quite common on hosters networks. In France, i only knows OVH (IIRC) who sends Router Advertisements on its network. In most of cases, server configuration is performed by static manual configuration.

Best regards
Emmanuel Thierry

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 15 Jan 2014 22:39:14 -0800 (PST)

Hi,

----- Original Message -----

> To: Alexandru Petrescu <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, 9 January 2014 6:16 AM

Just catching up on the list, will do so if it hasn't already been done (actually dug it up to do off-list a week or so ago, but will do it on-list now).

Regards,
Mark.

> underline

---

From: Christian Huitema <[email-masked]>
Date: Fri, 17 Jan 2014 05:47:07 +0000

> But maybe someone who has Christian's book could send a paraphrase

I have of course a few copies on my shelves. Mark ZZZ Smith is probably referring to the Chapter 4 of "IPv6, the new Internet Protocol," which was published in 1996. The chapter deals with "plug and play," and the first paragraph reads:

"By the end of June 1994, the IPng saga was coming to a close. The IPng selection committee had almost made up its' mind. The choice had to be based on the SIPP proposal, but SIPP could not be bought lock, stock, and barrel. A substantial number of directorate members thought that the 64-bit addresses were too narrow, that they would not provide enough flexibility to implement proper routing protocols. There was a compromise in sight, if only the SIPP proponents would agree to increase the address size to 128 bits. The IETF decision process is based on building consensus, part of which implies polling opinion leaders. I was one of those leaders by this time, or so they thought, so they polled me. Would I accept inflating the address to 128 bits? I had publicly stated many times that 64 bits was more than enough and I could back my opinion with substantial mathematical analysis. However, I did not hesitate too long. Going to 128 bits was a little price to pay to reach consensus and save the Internet. Moreover, 128-bit addresses have a definite advantage. They have twice the width that routing procedures require, hence they make a lot of room avail-able for proper implementation of auto configuration procedures. "

I then go on to explain how auto configuration works by concatenation of a network prefix and a unique identifier of the host, normally a MAC address. The 1996 version of the book was written before the ND specifications was finalized, and does not actually specify the 64 bit prefix size. Many examples show an 80 bit prefix and a 48 bit MAC address.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Jan 2014 08:59:17 +1300

Yes, Christian's explanation of "Why 128?" corresponds to what
I remember (and of course there were also arguments for a variable
length format, but that is another thread entireley).

>  Many examples show an 80 bit prefix and a 48 bit MAC address.

Indeed - and the story about EUI-64 came a little later, after
RFC 1884 and during the development of draft-ietf-ipngwg-addr-arch-v2.
Some archive trawling suggests that Firewire addresses were first
mentioned during an IPng Working Group interim meeting,
February 27 & 28, 1997, Palo Alto, CA USA. The context was a
discussion of the 8+8 proposal.

https://www.sixxs.net/archive/docs/ipng-archives/

    Brian

On 17/01/2014 18:47, Christian Huitema wrote:
> "By the end of June 1994, the IPng saga was coming to a close. The IPng selection committee had almost made up its' mind. The choice had to be based on the SIPP proposal, but SIPP could not be bought lock, stock, and barrel. A substantial number of directorate members thought that the 64-bit addresses were too narrow, that they would not provide enough flexibility to implement proper routing protocols. There was a compromise in sight, if only the SIPP proponents would agree to increase the address size to 128 bits. The IETF decision process is based on building consensus, part of which implies polling opinion leaders. I was one of those leaders by this time, or so they thought, so they polled me. Would I accept inflating the address to 128 bits? I had publicly stated many times that 64 bits was more than enough and I could back my opinion with substantial mathematical analysis. However, I did not hesitate too long. Going to 128 bits was a little price to pay to reach conse
nsus and save the Internet. Moreover, 128-bit addresses have a definite advantage. They have twice the width that routing procedures require, hence they make a lot of room avail-able for proper implementation of auto configuration procedures. "

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 17 Jan 2014 16:00:30 -0800 (PST)

Hi,

----- Original Message -----
> From: Christian Huitema <[email-masked]>
> To: Brian E Carpenter <[email-masked]>; Alexandru Petrescu <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Friday, 17 January 2014 4:47 PM
> Subject: RE: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]
> 
> 
> I have of course a few copies on my shelves. Mark ZZZ Smith is probably 
> referring to the Chapter 4 of "IPv6, the new Internet Protocol," which 
> was published in 1996.

The edition I have is the 1998 2nd edition, and the text which I found most interesting regarding the history of the address size choice was in the Points of Controversy section, starting on page 77, of the "Routing and Addressing" chapter, which described considerations such as geographic based addressing, variable length addressing and the 8+8 proposal.

I'd still recommend people get the book even though it was last published in 1998, because the "Points of Controversy" sections at the end of each chapter provide so much insight into why IPv6 was designed the way it was. I've found the "whys" and "why nots" of the designs of things to be as useful if not sometimes more useful than the "whats", and this is one of the few networking books that I have that captures quite a lot of the "whys". (Radia Perlman's "Interconnections", 2nd edition is another one.)

Regards,
Mark.

> The chapter deals with "plug and play," and the 
> first paragraph reads:
> 
> "By the end of June 1994, the IPng saga was coming to a close. The IPng 
> selection committee had almost made up its' mind. The choice had to be based 
> on the SIPP proposal, but SIPP could not be bought lock, stock, and barrel. A 
> substantial number of directorate members thought that the 64-bit addresses were 
> too narrow, that they would not provide enough flexibility to implement proper 
> routing protocols. There was a compromise in sight, if only the SIPP proponents 
> would agree to increase the address size to 128 bits. The IETF decision process 
> is based on building consensus, part of which implies polling opinion leaders. I 
> was one of those leaders by this time, or so they thought, so they polled me. 
> Would I accept inflating the address to 128 bits? I had publicly stated many 
> times that 64 bits was more than enough and I could back my opinion with 
> substantial mathematical analysis. However, I did not hesitate too long. Going 
> to 128 bits was a little price to pay to reach consensus and sa
> ve the Internet. Moreover, 128-bit addresses have a definite advantage. They 
> have twice the width that routing procedures require, hence they make a lot of 
> room avail-able for proper implementation of auto configuration procedures. 
> "
> 
> I then go on to explain how auto configuration works by concatenation of a 
> network prefix and a unique identifier of the host, normally a MAC address. The 
> 1996 version of the book was written before the ND specifications was finalized, 
> and does not actually specify the 64 bit prefix size. Many examples show an 80 
> bit prefix and a 48 bit MAC address.
> 
> 
> -- Christian Huitema
> 
>