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
