subnet prefix length > 64 breaks IPv6?

Mailman List Mirror (Read Only)
1

Hi,

I am trying to understand why standards say that "using a subnet
prefix length other than a /64 will break many features of IPv6,
including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND)
[RFC3971], .. " [reference RFC 5375]

Or "A number of other features currently in development, or being
proposed, also rely on /64 subnet prefixes."

Is it because the 128 bits are divided into two 64 bit halves, where
the latter identifies an Interface ID which is uniquely derived from
the 48bit MAC address.

I am not sure if this is the reason as this only applies to the link
local IP address. One could still assign a global IPv6 address. So,
why does basic IPv6 (ND process, etc) break if i use a netmask of say
/120?

I know that several operators use /120 as a /64 can be quite risky in
terms of ND attacks. So, how does that work? I tried googling but
couldnt find any references that explain how IPv6 breaks with using a
netmask other than 64.

Glen

2

I am not sure if this is the reason as this only applies to the link
local IP address. One could still assign a global IPv6 address. So,
why does basic IPv6 (ND process, etc) break if i use a netmask of say
/120?

As long as you assign addresses statically, IPv6 works just fine with a
netmask > 64. We've been using this for several years now. No problem.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

3

Ok. So does SLAAC break with masks > 64?

Glen

4

"Break" is not the right word. SLAAC only works with /64, But that is by
design.

Regards, K.

5

Ok. So does SLAAC break with masks> 64?

"Break" is not the right word. SLAAC only works with /64, But that is
by design.

SLAAC only works with /64 - yes - but only if it runs on Ethernet-like
Interface ID's of 64bit length (RFC2464).

SLAAC could work ok with /65 on non-Ethernet media, like a
point-to-point link whose Interface ID's length be negotiated during the
setup phase.

Other non-64 Interface IDs could be constructed for 802.15.4 links, for
example a 16bit MAC address could be converted into a 32bit Interface
ID. SLAAC would thus use a /96 prefix in the RA and a 32bit IID.

IP-over-USB misses an Interface ID altogether, so one is free to define
its length.

Alex

6

SLAAC only works with /64 - yes - but only if it runs on Ethernet-like
Interface ID's of 64bit length (RFC2464).

Ok, the last 64 bits of the 128 bit address identifies an Interface ID
which is uniquely derived from the 48bit MAC address (which exists
only in ethernet).

SLAAC could work ok with /65 on non-Ethernet media, like a
point-to-point link whose Interface ID's length be negotiated during the
setup phase.

If we can do this for a p2p link, then why cant the same be done for
an ethernet link?

Glen

7

it only breaks the auto configure crap which you don't want to use anyway.

(unless you want to have any computer on your network be able to tell any other computer "oh hai i'm a router, please route all your packets through me so i can intercept them" and/or flood its route table :wink:

we use all kinds of things from /126'es to /112 (but hardly any /64 crap)

works perfectly fine.

as long as its nibble aligned (for other reasons :wink:

8

I think by "point-to-point", Alexandru was referring to PPP-signalled
links. In the case of Ethernet and SLAAC, the standards define a way to
turn a globally unique 48-bit 802.3 MAC-48 address into an EUI-64
identifier by flipping and adding some bits.

This uniquely maps conventional MAC-48 addresses into EUI-64 addresses. I
imagine this was chosen because the IEEE is encouraging new standards and
numbering schemes to use the 64-bit schemes over the older 48-bit ones.
Presumably to avoid exhaustion in the future (like we're seeing with IPv4).

The result of which is that with the standards we've got today, we can
easily map a piece of hardware's globally unique MAC address into a
globally unique 64-bit identifier -- which happens to cleanly fit into the
second half of the v6 address space.

I suppose one could make an argument to use /80 networks and just use the
MAC-48 identifier for the address portion, but given the vastness of v6
space I don't think it's really worth the extra savings of bit space.

So, to address your original question, in v6 networks with netmask lengths
greater than 64 bits nothing "breaks" per se, but some of the conventional
standards and ideas about what a "network" is in that context are broken.
While it's not possible to have hosts uniquely pick addresses for
themselves, one can use other addressing mechanisms like DHCPv6 or static
addresses.

--j

9

things that -do- break on ipv6 a lot (not nessesarily related to the /64 thing) are premature protocols like ospf6 and ripng that for some magic reason refuse to work on point-to-point (as opposed to putting the interface in broadcast mode, like ethernet) interfaces without (additional) link-local addresses, despite the option to clearly specify the interface and/or address of the peer and/or address ranges they should work on (these do not nessesarily have to be /64, but they do need to be scope link local and start with a multicast prefix).

also various bgp implementations will send the autoconfigure crap ip as the next-hop instead of the session ip, resulting in all kinds of crap in your route table (if not fixed with nasty hacks on your end :wink: which doesn't exactly make it easy to figure out which one belongs to which peer
all the more reason not to use that autoconfigure crap :wink:

on the whole, ipv6 simply still needs a -lot- of work.

for those that do want autoconfigure (workstations?) , a proper dhcp implementation would be preferred over keeping that RA stuff around in future implementations of the v6 stack, as far as we're concerned, it can go the way of the dinosaur (already :wink:

10

Your understanding of IPv6 is poor if you think by not using a 64-bit
prefix you will be protected against rogue RA.

The prefix length you define on your router will have no impact on a
rogue RA sent out. IPv6 hosts can have addresses from multiple
prefixes on the same link. Choosing to make use of a 120-bit prefix
(for example) will do nothing to protect against a rogue RA announcing
its own 64-bit prefix with the A flag set.

You can use a 64-bit prefix and not use SLAAC as well. SLAAC is used
only when the A flag is set. It just so happens that the majority of
router implementations have it set by default.

You still need to filter RA from unauthorized hosts. Currently, many
switches can accomplish this using a PACL on access ports. In the
near future, we will begin to see the RA Guard feature become standard
on enterprise switches.

Mind you, you should be filtering out rogue RA regardless if whether
or not you have deployed IPv6. Windows ICS sending RA is a widespread
problem (honestly wish Microsoft would remove ICS from the default
install).

There are some things that will break by not using a 64-bit prefix.
SLAAC can't function without it. Privacy Extensions for SLAAC can't
either (obviously).

If you make use of a longer prefix, then you need to use either manual
configuration or DHCPv6 for address assignment.

All standards-compliant implementations of IPv6 will work with
prefixes longer than 64-bit. In production, we make use of 126-bit
prefixes for link networks, and common use of 120 (and similar)
prefixes for host networks and they work perfectly.

That said, the only reason we don't make use of 64-bit prefixes for
host networks is in an effort (which may be futile) to mitigate
neighbor table exhaustion attacks. We still reserve a full 64-bit
prefix, allowing us to expand the prefix in the future without
disrupting service. The long term plan is to migrate to 64-bit
prefixes when routing equipment is better able to handle neighbor
table exhaustion attacks.

As for the comments on the use of multicast; multicast is a good
thing. On most devices is is no different than broadcast, but it adds
the information needed for more advanced hardware (e.g. managed
switches with MLD snooping) to only replicate the traffic to
interested parties. The elimination of broadcast traffic in IPv6 is a
good thing, and doesn't introduce any problem.

The (related) other comment made was using ARP with IPv6 instead of
ND. This also shows a poor understanding of how IPv6 works. ARP is
for IPv4, ND is for IPv6. There is no ARP for IPv6. ND has the
advantage that it actually happens over IPv6, rather than a lower
level or parallel protocol. This makes filtering such traffic and
designing hardware that is aware of it significantly easier. It will
be nice to reach a point where non-IPv6 traffic can be filtered and
dropped completely. Other than making use of the link-local scope and
using a multicast group instead of broadcast, ND is pretty much the
same thing as ARP.

11

Hi Ray,

prefixes on the same link. Choosing to make use of a 120-bit prefix
(for example) will do nothing to protect against a rogue RA announcing
its own 64-bit prefix with the A flag set.

I could not find any "A flag" in the RA. Am i missing something?

From http://www.iana.org/assignments/icmpv6-parameters:

Registry:
RA Option Bit Description Reference
------------- --------------------------------------- ---------
0 M - Managed Address Configuration Flag [RFC2461]
1 O - Other Configuration Flag [RFC2461]
2 H - Mobile IPv6 Home Agent Flag [RFC3775]
3 Prf - Router Selection Preferences [RFC4191]
4 Prf - Router Selection Preferences [RFC4191]
5 P - Neighbor Discovery Proxy Flag [RFC4389]
6-53 R - Reserved; Available for assignment [RFC5175]
54-55 Private Experimentation [RFC5175]

Glen

12

> prefixes on the same link. Choosing to make use of a 120-bit prefix
> (for example) will do nothing to protect against a rogue RA announcing
> its own 64-bit prefix with the A flag set.
>

I could not find any "A flag" in the RA. Am i missing something?

It's part of the Prefix Information option. See

     RFC 4861 - Neighbor Discovery for IP version 6 (IPv6)

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

13

Sven,

also various bgp implementations will send the autoconfigure crap ip as the
next-hop instead of the session ip, resulting in all kinds of crap in your
route table (if not fixed with nasty hacks on your end :wink: which doesn't
exactly make it easy to figure out which one belongs to which peer
all the more reason not to use that autoconfigure crap :wink:

As per RFC 2545 BGP announces a global address as the next-hop. Its
only in one particular case that it advertises both global and link
local addresses.

So, i guess, BGP is not broken.

Its only RIPng afaik that mandates using a link local address.

Glen

14

It seems ISIS and OSPFv3 use the link local next-hop in their route
advertisements.

We discussed that SLAAC doesnt work with prefixes > 64 on the ethernet
medium (which i believe is quite, if not most, prevalent). If thats
the case then how are operators who assign netmasks > 64 use ISIS and
OSPF, since these protocols will use the link local address?

I had assumed that nodes derive their link local address from the
Route Advertisements. They derive their least significant 64 bytes
from their MACs and the most significant 64 from the prefix announced
in the RAs.

Glen

15

No, on Ethernet-ish networks the link-local is derived from an 'fe80::' and the MAC.

16

No, link local addresses are not derived from RAs. Even a system not connected to a router will have a link local address on each ethernet (I couldn't tell you how link local works on PPP, ATM, etc, without looking it up - but it doesn't require /64 networks).

17

Each prefix on an interface can have a different prefix length.
Link-locals always have a prefix length of 64, even if a global
address assigned to the same interface has a different length. Also,
the link-local address is derived locally without any information from
RAs.

18

For stateless autoconfig the issue is that it uses 64-bit "interface identifiers" (~ MAC addresses) that are supposed to be globally unique. You can't shave off bits and remain globally unique.

With SEND a cryptographic hash that can be used to determine address ownership is stored in the interface identifier. Here shaving off addresses reduces security.

Also somehow the rule that all normal address space must use 64-bit interface identifiers found its way into the specs for no reason that I have ever been able to uncover. On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on > /64 is somewhat less efficient.

19

This ambiguity has always bothered me. The address architecture RFC
requires a 64-bit interface identifier, but it's required to be
unenforced by implementation, which makes it more of a suggestion at
best. I think the wording should be updated to changed MUST to
SHOULD. That said, and despite my own use of prefix lengths other
than 64-bit, I do believe that a 64-bit prefix for each host network
is in our long-term interest. Not having to size networks based on
the number of hosts is a good thing. Features made possible by a
64-bit address space is a good thing.

20

On the other hand there's also the rule that IPv6 is classless and therefore routing on any prefix length must be supported, although for some implementations forwarding based on > /64 is somewhat less efficient.

Can you please name names for the "somewhat less efficient" part? I've
seen this and similar claims several times, but the lack of specific
information is rather astounding.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no