Subject: [v6ops] FF LARA for IPv6?

From: Saku Ytti <[email-masked]>
Date: Mon, 8 Feb 2016 17:08:48 +0200

LARA[0] might have attractive properties in IPv6.

Consider MAC address today has 46bits of usable bits, local scope must
be set, multicast must be unset.
IPv6 speaker could use some algorithm to produce 46 bits identifier
and subsequently populate MAC address with it, and combine it with
IPv6 prefix to produce IPv6 address.

Obviously subnet can be larger than than 46bits, but that gives us
another interesting advantage. Consider /64 subnet, where we have
64bits for hosts. This means ID is only sufficient to fill 46 of those
hosts bits, and we'd be left with 18 unfilled host bits.
Now router would forward all these 18 bits addresses to same 46bits
identifier, i.e. same MAC address.
This means every IPv6 host in LAN, now essentially have18 bits routed
LAN, with 0 config on router. Feature which I've always thought is
missing in IPv6. What is the point of having addresses, without having
routing.

The major problem I see with potential IPv6 implementation is how to
produce that unique identifier, there needs to be some sort of DAD,
but how do you do DAD when you can't rely on uniqueness of MAC? Do you
first use BIA to do DAD before you choose your ID?
What about co-existence of LARA and normal ND in same LAN, is it
possible? Is it necessary? Can RA declare LAN to be LARA LAN?

I hope the other benefits, than this automatic subnetting are more
obvious and not needed to iterate. But it means stateless resolution,
no ND exhaustion, no attack vectors, no unscalable multicast group in
LAN,  trivial and robust stateless 'IPSG/DAI'.

[0] https://datatracker.ietf.org/doc/draft-eromenko-ipff-lara/
-- 
  ++ytti

---

From: Mark Smith <[email-masked]>
Date: Tue, 9 Feb 2016 06:34:38 +1100

> IPv6 prefix to produce IPv6 address.

So this looks to be basically a re-invention of how DECnet Phase IV
did layer 3 to layer 2 - search for "HIORD".

"DECnet, DIGITAL Network Architecture, Routing Layer Functional
Specification, Version 2.0.0, May 1983"

http://linux-decnet.sourceforge.net/docs/route20.txt

One of the drawbacks, which is probably a show stopper, is that it
limits the number of layer 3 addresses on a link to the maximum number
of layer 2 addresses supported on a link. While links with large
numbers of layer 2 addresses are common, tightly coupling the size of
the layer 3 address space on a link to the size of the available layer
2 address space is probably an unacceptable layer 3 limitation.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Saku Ytti <[email-masked]>
Date: Mon, 8 Feb 2016 21:45:12 +0200

> 2 address space is probably an unacceptable layer 3 limitation.

Can you elaborate on the problem? I think it only limits that every L3
subnet will have same identifier (can be different size L3 network
though).

-- 
  ++ytti

---

From: Mark Smith <[email-masked]>
Date: Tue, 9 Feb 2016 08:17:58 +1100

> subnet will have same identifier (can be different size L3 network

Actually my criticism above is not quite right, although I think on the
right path.

With a smaller layer 2 address space, the likelihood of hash collisions
goes up, so this doesn't eliminate the issue of dealing with duplicate
addresses, and creates it at layer 2  where no DAD solution currently
exists.

Another issue is Node support for multiple layer 3 addresses. That would
likely translate into multiple layer 2 addresses, meaning nodes need to
support multiple MAC addresses. I think some NICs support that, but most
would have to be switched into promiscuous mode, disabling all NIC level
address based filtering.

Also, as there is no neighbour presence discovery protocol, every unicast
layer 3 packet translates into a layer 2 frame, even if the layer 3 and
therefore layer 2 destination doesn't exist. That's an opportunity for a
flooding attack at layer 2, because bridges and switches will flood those
unknowns to all devices - and nodes with NICs in promiscuous mode will hand
all of them up to the main CPU to be thrown away.

---

From: Saku Ytti <[email-masked]>
Date: Mon, 8 Feb 2016 23:23:13 +0200

On 8 February 2016 at 23:17, Mark Smith <[email-masked]> wrote:

> With a smaller layer 2 address space, the likelihood of hash collisions goes
> up, so this doesn't eliminate the issue of dealing with duplicate addresses,
> and creates it at layer 2  where no DAD solution currently exists.

If you use BIA when doing DAD, you can verify your ID is unique. And
you can verify it on link-local scope, so you verify all 46 bits for
uniqueness at once, regardless what your GUA prefix-size is.

> would have to be switched into promiscuous mode, disabling all NIC level

Why? Just fill all the host bits you need, from the 46 bits ID you
have, for every prefix you have.

> all of them up to the main CPU to be thrown away.

Unknown unicast is easily HW limited by switch, and should be done
anyhow, regardless how L2 network is ran, so this protection should
already be in place. ARP/ND resolution is HW limited as well, as to
avoid punting too much to control-plane.

-- 
  ++ytti

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Feb 2016 10:34:01 +1300

I'm not quite sure why we're having this discussion on the operations
list when it's a protocol design issue, and one that has been
actively debated on the 6man list for some years, resulting in:
 	
RFC 6164
RFC 7136 	
RFC 7217
RFC 7421 	
draft-ietf-6man-ipv6-address-generation-privacy
draft-ietf-6man-default-iids

and some of the wording details in draft-ietf-6man-rfc4291bis

Regards
   Brian

---

From: Saku Ytti <[email-masked]>
Date: Mon, 8 Feb 2016 23:39:21 +0200

> list when it's a protocol design issue, and one that has been

Yeah maybe 6man would be better.

> and some of the wording details in draft-ietf-6man-rfc4291bis

I don't think any of these propose method for doing away with ND
resolution and cache.

-- 
  ++ytti

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Feb 2016 10:53:53 +1300

> I don't think any of these propose method for doing away with ND

I am quite sure they don't.

    Brian