Re: [Anima] Is this how BRSKI/IPIP works?

[Brian E Carpenter <[e-mail]>]

On 12/07/2017 12:44, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> wrote:
>     > Is the following correct?
> 
>     > Topology (ASCII art):
> 
> Topology is essentially correct.
> As you point out, RFC7217 is the recommendation going forward, so having
> a a big IEEE OUI allocation isn't necessary anymore.
> 
> But, the problem is you have a single Ax for the device.
> The ACP needs to allocate Ax1 for LAN1, and Ax2 for LAN2, etc.

Yes, that would disambiguate it. But in general it isn't necessary for
a node to have multiple ACP addresses just because it has multiple
interfaces, is it?

> That's why I
> wanted a /96 or so provided by the ACP to each device.

That would be one way, but it will create noise in 6man.
In any case if the requirement is one address per proxy+interface
I'm sure it can be done somehow; IPv6 addresses are cheap.

> So it becomes:
> 
>> Pledge sends to proxy [Lp, Lx1, 17, UDP-PAYLOAD1]
>> Proxy sends to Registrar [Ax1, Ar, 41,   [Lp, Lx1, 17, UDP-PAYLOAD1]]
>> Registrar replies to proxy [Ar, Ax1, 41, [Lx1, Lp, 17, UDP-PAYLOAD2]]
>> Proxy replies to pledge [Lx1, Lp, 17, UDP-PAYLOAD2]
> 
> Toerless says that a non-priveledged process (the proxy) can't easily
> configure additional LL addresses.  That's true. It also can't configure the
> addresses for the ACP.  The ACP needs to do that.
> 
> The Lx1 and Lx2 could be identical, although I'd not want to design my device
> that way.  I looked at the CDP/LLDP spec, and both are unclear what the
> source L2 address is.
> 
>     > So, what the registrar needs to tell the proxy is: I accept IP in IP on
>     > address Ar.  Nothing else - no port number, no link-local address.
> 
> There is a small problems with this.  With a UDP transport, we simply
> have to arrange for the registrar to accept traffic to any LxX IP address.
> That's not stock POSIX, but it's not that hard.  LxX state can be handled
> by the application.  With TCP the kernel has be rather flexible, being
> able to keep duplicate Lp<->Lx1 connections seperate in the kernel, and
> at the same time, permitting any LxX on the Registrar's side.
> 
> Instead, I have two suggestions, not entirely mutually exclusive:
>   1) the Registrar says, "I accept IPIP on Address Ar, use Lr for connections"

I don't understand where Lr would be used. The LL messages are
all between the pledge and the proxy, which have perfectly fine
LL addresses of their own.

>   2) we make Lr = well known Link-Local anycast address
> 
> In my implementation, I dynamically set up an IPIP interface for each Lx
> on each proxy that appears.  The kernel assigns a new ifindex to each of
> these interfaces, and the normal LL-requires-ifindex rules apply to
> distinguish things.  This requires a retransmission since the first time
> there is a packet from a new Ax1/LAN1, the packet does not match any current
> IPIP tunnel, and is dropped by the kernel.  A process watches for these
> and configures them LRU.
> 
>     > What the proxy needs to tell the pledge is: I accept BRSKI/TCP or
>     > BRSKI/UDP on address Lx. And if it chooses to use IPIP to contact the
>     > registrar, it simply forwards the packets as-is in both directions,
>     > encapsulating and decapsulating accordingly. The pledge knows nothing
>     > about IPIP.
> 
> It needs to know it's IPIP,

Why? The IPIP encapsulation and decapsulation can happen inside the proxy
(and the registrar). Why does the pledge care?

> but I think you mean, it knows nothing about
> what's inside the inner IP header.   There is some work (which I've yet to
> complete) to arrange to forward LL-IP packets coming out of the IPIP
> interface to the physical interface, since LL packets are normally never
> forwarded.  Really, this is a kind of bridge (that's what I'll tell the
> v6-police).
> 
> As for Toerless' notion that we should invent a new UDP-based encapsulation

IPv6-over-UDP isn't exactly a new invention. It's been used in Teredo,
TSP (RFC5572) and SixXs (https://tools.ietf.org/html/draft-massar-v6ops-ayiya-02).
More to the point, draft-ietf-intarea-gue is in progress.

All the same, if straight IPIP works, so much the better.

   Brian

> rather than use the well defined IPIP encapsulation, I have really no comment.
> I'm pretty sure that many will want to leverage existing v6-extension header
> chasing hardware for the purpose of auditing, which is why I prefer not
> to invent new on-the-wire formats just to so that some software engineer can
> avoid having to learn a new API call.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
>