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

[Michael Richardson <[e-mail]>]

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.

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)

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).

    >> > 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.

    >> 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.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-