Re: [Anima] Is this how BRSKI/IPIP works?
Toerless Eckert <tte@cs.fau.de> Mon, 17 July 2017 08:02 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DEE131A63 for <anima@ietfa.amsl.com>; Mon, 17 Jul 2017 01:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jziu0hNsaP3g for <anima@ietfa.amsl.com>; Mon, 17 Jul 2017 01:02:18 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12348131A55 for <anima@ietf.org>; Mon, 17 Jul 2017 01:02:18 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1174F58C4B5; Mon, 17 Jul 2017 10:02:14 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D0C4AB0C5EA; Mon, 17 Jul 2017 10:02:13 +0200 (CEST)
Date: Mon, 17 Jul 2017 10:02:13 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: "Eliot Lear (elear)" <elear@cisco.com>
Cc: Eliot Lear <lear@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Anima WG <anima@ietf.org>
Message-ID: <20170717080213.GE23525@faui40p.informatik.uni-erlangen.de>
References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <14885.1499820271@dooku.sandelman.ca> <20170716182749.GC23525@faui40p.informatik.uni-erlangen.de> <23694.1500273241@dooku.sandelman.ca> <ac374936-2718-c737-e871-e9f97ea6f78a@cisco.com> <20170717073859.GD23525@faui40p.informatik.uni-erlangen.de> <7B3FD2E7-D0B8-4F7F-A583-D125ECA2F70E@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7B3FD2E7-D0B8-4F7F-A583-D125ECA2F70E@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/XZhrZGgM4Gb0hm5wsVVmnXWdNus>
Subject: Re: [Anima] Is this how BRSKI/IPIP works?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jul 2017 08:02:20 -0000
Remember that the pledge can only have a link-local address during bootstrap, so i would not know how to interpret your comment. Cheers Toerless On Mon, Jul 17, 2017 at 07:41:40AM +0000, Eliot Lear (elear) wrote: > Sure. Use normal unicast addresses (ULA or other) if available. > > Eliot > > > On Jul 17, 2017, at 9:39 AM, Toerless Eckert <tte@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 <tte@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 [ > >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > >>> > >>> > >>> -- > >>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works > >>> -= IPv6 IoT consulting =- > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >> > > > > > > > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de
- Re: [Anima] Is this how BRSKI/IPIP works? Toerless Eckert
- [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Toerless Eckert
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Toerless Eckert
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Toerless Eckert
- Re: [Anima] Is this how BRSKI/IPIP works? Michael Richardson
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Michael Richardson
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Michael Richardson
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Eliot Lear
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Eliot Lear
- Re: [Anima] Is this how BRSKI/IPIP works? Michael Richardson
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Michael Richardson
- Re: [Anima] Is this how BRSKI/IPIP works? Michael Richardson
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Toerless Eckert
- Re: [Anima] Is this how BRSKI/IPIP works? Eliot Lear
- Re: [Anima] Is this how BRSKI/IPIP works? Toerless Eckert
- Re: [Anima] Is this how BRSKI/IPIP works? Michael Richardson
- Re: [Anima] Is this how BRSKI/IPIP works? Eliot Lear
- Re: [Anima] Is this how BRSKI/IPIP works? Brian E Carpenter
- Re: [Anima] Is this how BRSKI/IPIP works? Toerless Eckert
- Re: [Anima] Is this how BRSKI/IPIP works? Eliot Lear (elear)
- Re: [Anima] Is this how BRSKI/IPIP works? Toerless Eckert
- Re: [Anima] Is this how BRSKI/IPIP works? Michael Richardson
- Re: [Anima] Is this how BRSKI/IPIP works? Toerless Eckert
- Re: [Anima] Is this how BRSKI/IPIP works? Max Pritikin (pritikin)