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

["Eliot Lear (elear)" <[e-mail]>]

Sure. Use normal unicast addresses (ULA or other) if available. 

Eliot

> On Jul 17, 2017, at 9:39 AM, Toerless Eckert <[e-mail]> 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 <[e-mail]> 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  [
>>> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
>>> 
>>> 
>>> --
>>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Anima mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/anima
>> 
> 
> 
> 
> 
> -- 
> ---
> [e-mail]