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

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

OK, I'm getting there. More in line:

On 13/07/2017 03:57, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> 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?
> 
> We need a way to distinguish the different links (and scoope of the LL
> address) in a way that can be communicated easily and cheaply to the
> Registrar.    I've asked for the "V"irtualization bit to be bigger, and I see
> no purpose for the Zone-ID myself.
> 
>     >> 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.
> 
> It's not a subnet for the device to announce, it's a large bag of /128s.
> 
>     >> 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.
> 
> Assume a TCP connection from the Pledge to the Registrar.
> It looks like, as you wrote:
> 
>    Pledge sends to proxy [Lp, Lx1, 17, TCP-PAYLOAD1]
> 
> On the registrar, when it emerges from the IPIP tunnel, this is what the
> registrar sees.   If we do nothing, the Registrar says, "Lx1"? What's that
> it's not me. Drop.  So we have to do something. Options are:
> 
> 1) Registrar accepts any Lx1 as local.
> 2) We pick a well-known Lx value (a LL anycast).
> 3) We have the Registrar tell the proxy an Lx value to use.
> 
> 
> 1) Registrar accepts any Lx1 as local.
>    There is no precedent in v6 APIs to open such a socket, but this actually
>    supported on many platforms.  It's used for nasty stuff like transparent
>    application layer proxies, forced HTTP proxying, and the like.

I think there's a more subtle way to look at it. When the registrar receives
a protocol 41 packet from a new ACP address, it conceptually synthesises
a new virtual interface and assigns Lx1 as its link local address. On
that interface, things would look normal. Thus RFC2473:

>>  The tunnel link-layer input and output can be implemented similar
>>  to the input and output of other link-layer protocols, for
>>  instance, associating an interface or pseudo-interface with the
>>  IPv6 tunnel.

I really think this is a clean approach. In any case, what happens to
a protocol 41 packet is always a bit strange and is not covered by
the traditional socket model.
> 2) We pick a well-known Lx value (a LL anycast).
>    The pledge has to do something slightly funky where it forces a particular
>    L2 address for the anycast LL, because if there are multiple proxies on
>    the network, straight ND will get one at random, and the Pledge actually
>    wants to be specific about which one it uses. (since it wants to try them all)

How can it work as anycast if is more than one proxy on the LAN?
I'm not at all clear that anycast under fe80::/10 makes much sense.

> 3) We have the Registrar tell the proxy an Lx value to use.
>    I chose to put this option into the protocol, because we can always
>    set Lx= Lanycast in the future, and perhaps we can set it to ::
>    if we want case (1).

I like this least of all. What happens if there are multiple registrars?
And when a proxy node comes up as a pledge, it must give itself a LL address
on each interface before it even tries to perform its own BRSKI, and before
it looks for its own proxy and joins the ACP. Is it supposed to change its
own LL address after it discovers the registrar? Or is it supposed to
have two simultaneous LL addresses? Is that even possible?
 
>     >> > 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?
> 
> Sorry. "Proxy" vs "Pledge"
> "IT" above referred to Proxy, but in fact it says "pledge". Typo.

OK!

> 
>     >> 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.
> 
> I resorted to using Ar as an additional signaling mechanism to "store" the
> ifindex where the request was coming from rather than try to find some bits
> in some other protocol like one you mention above.
> TSP is too complex for our needs.
> 
> Teredo has some space for additional stuff. It should be straight forward to
> define it over IPv6 rather than v4. Seems a bit weird to me though.

Yes. My point was only that this isn't uncharted territory.

   Brian