On 12/07/2017 12:44, Michael Richardson wrote: > > 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.
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 [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > > > > > > > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
