Brian E Carpenter <[email protected]> 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. That's why I
wanted a /96 or so provided by the ACP to each device.
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"
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, 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
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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
