Sure. Use normal unicast addresses (ULA or other) if available. Eliot
> On Jul 17, 2017, at 9:39 AM, Toerless Eckert <t...@cs.fau.de> wrote: > > Can you propose a stateless proxy model that would not pass the link-local > addresses on to the registrar and that uses Michaels beloved IPinIP encap ? > > Alas i have fallen in love with UDP encap because i like to see more > networking software now be build like any othrer application on top of > UDP/TCP APIs and not mess around with OS kernel features, so all > my answers would be "the proxy is an app that either statefully proxies TCP > or stateless proxies UDP". > > If you want to statelessly proxy TCP and on the registrar use some existing > TCP stack, then i would begrudgingly agree with Michael, that i also need some > kerne level handling of the encap so that i get kernel level TCP. > > I am still waiting for some better explanation from Michael about the > "Linux kernel and overlapping TCP" to fully understand his proposal. > > So, here is one proposal for IPinIP using the current -07 draft ULA > addressing: > > A) We assign one of the 8 (3 bit) "T"ype codes to "Subnet Identifier for > Encap". > > B) The proxy allocates a separate "Zone" number for every subnet. Zone = > Subnet. > In result it now has for every subnet a separate ULA address for the > IPinIP encap. > > C) The registrar announces its ability to support IPinIP BRSKI via GRASP > > D) Each ACP device need to use its ACP DeviceID also as the host-part of its > link-local address. > > E) The proxy as part of its tunnel functionality also assigns itself the > Registrar > link local address on every subnet. At least logically. Whether it really > needs > to do this physcially is implementation specific. > > F) The proxy announces via GRASP BRSKI-IPIP with the Registrar Link-Local > address > (which it can do because according to E) it owns it on its subnets - GRASP > DULL does not permit third-party announcements, so E) is to make it legal > for > the proxy to announce this in GRASP). > > G) Any packets sent by pledges to the Registrar link-local address are IPinIP > encapsulated using the "Subnet Identifier for Encap" as the source IP > address and > the Registrar ULA as the destination address. > > H) The registrar can create a separate IPinIP tunnel per remote proxy, > per-subnet-on-proxy. > It does not need further addresses. > > Some more details might be needed, eg: > - If a proxy has more than 2^13 interfaces it needs to dynamically allocate > subnet encap addresses. > - A proxy might want to map different subnets to differen registrars for load > balancing. > > Cheers > Toerless > >> On Mon, Jul 17, 2017 at 08:54:46AM +0200, Eliot Lear wrote: >> On the other hand, maybe it's fundamental, but is relying on LL in this >> architecture to go beyond LL boundaries the right thing to do? >> >> >>> On 7/17/17 8:34 AM, Michael Richardson wrote: >>> Toerless Eckert <t...@cs.fau.de> wrote: >>>> I thought i had asked that question already but not sure, and not seen >>>> an answer: - I have never seen that a device has more than one >>>> link-local addr on an interface. Is this permitted by IPv6 arck ? Can >>>> you configure this in eg: Linux. I thought i tried on linux/cisco-ios >>>> in the past and i do not quite remember, but i think it failed (only >>>> one address). >>> >>> dooku-[~](2.3.0) mcr 10879 %sudo ip -6 addr add fe80::1234/64 dev wlan0 >>> >>> dooku-[~](2.3.0) mcr 10788 %ifconfig wlan0 >>> wlan0 Link encap:Ethernet HWaddr 08:11:96:01:81:e0 >>> inet addr:31.133.129.16 Bcast:31.133.143.255 Mask:255.255.240.0 >>> inet6 addr: fe80::1234/64 Scope:Link >>> inet6 addr: fe80::a11:96ff:fe01:81e0/64 Scope:Link >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>> >>> dooku-[~](2.3.0) mcr 10788 %ip -6 addr ls dev wlan0 >>> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 >>> inet6 fe80::1234/64 scope link >>> valid_lft forever preferred_lft forever >>> inet6 fe80::a11:96ff:fe01:81e0/64 scope link >>> valid_lft forever preferred_lft forever >>> >>> >>> -- >>> ] Never tell me the odds! | ipv6 mesh >>> networks [ >>> ] Michael Richardson, Sandelman Software Works | network architect >>> [ >>> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails >>> [ >>> >>> >>> -- >>> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works >>> -= IPv6 IoT consulting =- >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> > > > > > -- > --- > t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
