Subject: 6man: creating virtual multipoint interfaces

From: Toerless Eckert <[email-masked]>
Date: Tue, 8 Aug 2017 19:45:09 +0200

I am wondering if there is some RFC i could reference that defines the following
functionality specifically for IPv6. If not, i'll have to write it into
a draft of mine and would welcome suggestions on some details:

I have a full mesh of p2p tunnels between a set of routers, and i want
to make this look like a single multiaccess subnet for IPv6.  How i
create these tunnels is out of scope (resolved). The tunnels would carry
only IPv6 packets (not ethernet header etc..).

So, a node would enable link-local multicast on this virtual multi-access subnet
by just replicating it to all p2p tunnels. And now we run ND. And wonder
what to put into the link-layer address field. In my case we can assume
the nodes all have the same underlying L2 across which they runn the tunnels,
so as long as this is ethernet and we assume unique MAC addresses, we can just
use them. Otherwise we would need to come up with some other unique link-layer
address. Or we could simply leave this field empty and learn which tunnel
is connected to which IPv6 neighbor address by tracking the p2p tunnel frm
which the Neighbor advertisements arive. Could even be any unicast packets
source-address. Except that it is for a router (not having HW like an L2 switch)
easier to learn source addresses from protocols explicitly punted to a control plane
(like ND).

Existing references i could point to ? 
Sugestions for the detail (link-layer address encoding, learning of neighbor tunnel ?)

IMHO its pretty simple, but wanted to see i am not overlooking anything.

Thanks
    Toerless

Ikkn-Reply-To: <[email-masked]>

On Mon, Aug 07, 2017 at 08:38:44PM +0200, te36 wrote:
> 
> Thanks Daniel!
> 
> Quick browsing does not seem to show that these docs discuss what i am looking for,
> so let me explain it hopefully better:
> 
> Assume i have a p2p subnet with two routers attached. I want to use IPsec
> to protect all IPv6 traffic on that subnet and make it "invisible" to all
> IP protocols as much as possible. So i set up an IPsec SA between the two
> and set the SPD on both sides to protect all traffic. 
> 
> So this will work fine, and i vendors are supporting it, but i am not aware
> of an RFC specifying this. For example, what would you put into the Link-Layer
> address option of IPv6 ND packets. I assume this would be the underlying
> link-layer address (eg: ethernet address), but thats not 100% obvious.
> 
> So, thats the simple case. Lets consider now i have 3 (or 30) routers on a LAN and
> want to protect it with IPsec. Usually, i could not create multiple SAs
> across a single interface (from what i have seen in products). There are
> products that allow you to create a virtual IPsec subnet, but those are p2p,
> eg: you create a full mesh of SAs and on every router you see two separate
> virtual IPsec p2p interfaces, each operating the same as the above p2p example,
> except that the implementation might be different.
> 
> But i would rather like to see a single multiaccess subnet interface on each
> router so that i can fully reflect the underlying topology. And any protocols
> using multicast would continue to operate. Its not really that difficult,
> as i already said in my first email:
> 
>   - Replicate multicsts into all SAs. Including ND multicasts.
>   - You keep a mapping table about which IPv6 nexthop belongs to which SA.
>   - Send unicast into the right SA based on that nexthop table.
>   - Populate that nexthop table from source IPv6 addresses
>     received from each SA. Maybe limited to received ND packets.
>   - Continue to populate the the underlying Link-Layer address, but 
>     no need to maintain any link-layer mapping table (send but ignore on
>     receipt).
> 
> And now i just wonder if i need to write this down into my draft, or if i can
> find some existing RFC (or draft) i could refer to. Especially because the details
> of learning the SA mapping are pretty arbitrarily. Eg: I think it would logically
> be a lot better to have SPIs as link-layer addresses, but i wouldn't want to
> invent something new just because i think it's logically better. Or i
> populate the mapping table solely from the peer address of the SPI (eg:
> link-local-IPv6-address of the peer on the SA).
> 
> The definitions i am looking for does not need to be specific to IPsec. The
> problem is IMHO quite orthogonal to IPsec. Eg: instead of IPsec SA, i could
> equally try to protect the traffic with any other form of secure p2p tunnel.
> But i wouldn't know which other IETF mailing list to ask for other contexts
> (suggestions welcome).
> 
> There is for example rfc7847, but it has a lot of surplus (;-) mobility stuff
> in it, and it doesn't tackle the simple points of multicast, how to learn
> next-hop mapping , eg: what to do with ND packets, etc. pp, so i think it
> wouldn't help me as a reference.
> 
> Cheers
>     Toerless
> 
> On Mon, Aug 07, 2017 at 12:40:21PM -0400, Daniel Migault wrote:
> > Not really sure what exactly you are looking at, but these links might be > helpful.
> > 
> > https://tools.ietf.org/html/rfc7018
> > https://tools.ietf.org/html/rfc7791
> > https://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03
> > https://tools.ietf.org/html/draft-detienne-dmvpn-01
> > 
> > On Fri, Aug 4, 2017 at 7:37 PM, Toerless Eckert <[email-masked]> wrote:
> > 
> > > I want to describe (in some draft) the use of a virtual multi-access
> > > interface that is mapped to multiple p2p associations (eg: IPsec).
> > > Which i think is a pretty standard option in industry implementations, eg:
> > > in hub routers for hub & spoke deployments.
> > >
> > > Is there any good RFC reference that explains how this works, eg:
> > > replicate ll-multicast to all p2p associations, learn peer addresses
> > > from received packets or specific IPv6 signaling packets, use that
> > > to send unicast into right p2p association, etc. pp.
> > >
> > > I could not find a good reference RFC for this ;-(
> > >
> > > Thanks!
> > >     Toerless
> > >
> > > _______________________________________________
> > > IPsec mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ipsec
> > >
> 
> -- 
> ---
> [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Aug 2017 21:57:07 +0000

Hi Toerless,

We have been working with point-to-multipoint tunnels (actually NBMA) for a long
time. The earliest examples were RFC2529 and RFC5214, but we have carried the
model forward into our current AERO proposal:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

Of these proposals:

 - RFC2529 uses multicast-in-multicast encapsulation so that true multicast is used
   in the underlay.
- RFC5214 is unicast-only
- AERO can use either multicast-in-multicast or unicast-emulated multicast such
  as your message described.

All of these works use IPv6 ND messaging over tunnels.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Toerless Eckert
> Sent: Tuesday, August 08, 2017 10:45 AM
> To: [email-masked]
> Subject: 6man: creating virtual multipoint interfaces
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------