[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: RE: 6man: creating virtual multipoint interfaces
From: "Templin, Fred L" <Fred.L.Templin () boeing ! com>
Date: 2017-08-09 21:57:07
Message-ID: 02f135632b024a6182a8ad2202f57e82 () XCH15-06-08 ! nw ! nos ! boeing ! com
[Download RAW message or body]
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
fred.l.templin@boeing.com
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Toerless Eckert
> Sent: Tuesday, August 08, 2017 10:45 AM
> To: ipv6@ietf.org
> Subject: 6man: creating virtual multipoint interfaces
>
> 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: <20170807183844.GY3889@faui40p.informatik.uni-erlangen.de>
>
> 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 <tte@cs.fau.de> 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
> > > > IPsec@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ipsec
> > > >
> >
> > --
> > ---
> > tte@cs.fau.de
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic