Re: sockets APIs extensions for Host Identity Protocol
Miika Komu <miika@iki.fi> Sat, 12 May 2007 16:35 UTC
Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmuZC-0003xa-Br; Sat, 12 May 2007 12:35:34 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HmuZA-0003wV-UM for discuss-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 12:35:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmuZ8-0003v3-Jn for discuss@apps.ietf.org; Sat, 12 May 2007 12:35:31 -0400
Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmuZ4-0006KA-MA for discuss@apps.ietf.org; Sat, 12 May 2007 12:35:30 -0400
Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5A13B2D4E; Sat, 12 May 2007 19:35:17 +0300 (EEST)
X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322
X-Spam-Niksula: No
Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id AC8C42D4A; Sat, 12 May 2007 19:35:16 +0300 (EEST)
Date: Sat, 12 May 2007 19:35:16 +0300
From: Miika Komu <miika@iki.fi>
X-X-Sender: mkomu@kekkonen.cs.hut.fi
To: Keith Moore <moore@cs.utk.edu>
Subject: Re: sockets APIs extensions for Host Identity Protocol
In-Reply-To: <4644E478.1070804@cs.utk.edu>
Message-ID: <Pine.SOL.4.64.0705121809550.27730@kekkonen.cs.hut.fi>
References: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi> <20070507082737.GB21759@nic.fr> <46413DD7.8020702@cs.utk.edu> <20070509121703.GA21070@nic.fr> <4641CA52.70504@cs.utk.edu> <Pine.LNX.4.64.0705091449360.26169@hermes-1.csi.cam.ac.uk> <4641D94C.9070304@cs.utk.edu> <Pine.SOL.4.64.0705102013550.10049@kekkonen.cs.hut.fi> <46436B10.5090706@cs.utk.edu> <Pine.SOL.4.64.0705102159020.10049@kekkonen.cs.hut.fi> <4643F873.3000501@cs.utk.edu> <Pine.SOL.4.64.0705110851440.24038@kekkonen.cs.hut.fi> <46442588.7020405@cs.utk.edu> <Pine.SOL.4.64.0705111344130.16213@kekkonen.cs.hut.fi> <4644779F.60805@cs.utk.edu> <Pine.SOL.4.64.0705111801430.8816@kekkonen.cs.hut.fi> <4644CD76.10900@cs.utk.edu> <Pine.SOL.4.64.0705112330070.8816@kekkonen.cs.hut.fi> <4644D90B.1020304@cs.utk.edu> <Pine.SOL.4.64.0705120006150.8816@kekkonen.cs.hut.fi> <4644E478.1070804@cs.utk.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org
On Fri, 11 May 2007, Keith Moore wrote: Hi Keith, > Miika Komu wrote: >> On Fri, 11 May 2007, Keith Moore wrote: >> >>> please no. don't try to hide this stuff from the app in the low-level >>> API. the rest of the network keeps trying to force routing decisions >>> on the apps in the absence of routing information. ideally, the app >>> shouldn't have to be doing any routing or address selection or >>> anything. but at present, how to cope with this kind of world is an >>> unsolved problem, and the only place where experimentation can be done >>> towards learning how to solve that problem is at layer 7. if you >>> cripple the API, you prevent that kind of experimentation (at worst) or >>> (at best) increase the burden on the app writer by forcing him to write >>> his own kernel extensions. >>> >>> that, and you still need to expose IP addresses for diagnostic purposes. >>> >>> what do you gain from trying to hide the IP addresses? >> >> First, to discourage the use of IP addresses as referrals because >> application developer would have to fetch them using a separate >> function call. But maybe this is a weak justification... Second, the >> socket address structure is constrained to 255 bytes. It will fit >> "only" 1 HIT and 15 addresses. Is this enough for e.g. routers? > > perhaps strangely, the latter justification makes more sense to me. no, > 15 addresses is not enough. but it's not acceptable to have the IP > addresses passed implicitly from the resolver to the socket. Actually, the addresses passed from the resolver would be system level "hints" rather than bound to a specific socket because getaddrinfo resolver does not know anything about the sockets. What is the exact reason why you see this as an bad idea? > offhand, I'd say that a good compromise would be to allow some > reasonable number of addresses to be specified using sockaddr_hip and to > allow more peer addresses to be added using a setsockopt() call. I don't see how this would work with the resolver? I guess the only way would be to output several HITs redundantly, but with different IP addresses. Would this work for you? I thought about size limitations in more detail. A naive version of sockaddr_hip structure and its fields could look as follows based on the discussion: struct sockaddr_hip { uint8_t sinh_len; /* 1 byte */ sa_family_t sinh_family; /* 1 byte */ in_port_t sinh_port; /* 2 bytes */ struct in6_addr sinh_hit; /* 16 bytes */ struct sockaddr_in6 sinh_loc[2]; /* 2 * 112 bytes */ } /* total: 244 bytes (note: maximum size 255 bytes) */ Here I just put two IPv6 addresses inside the structure and assume that we use IPv4 address in IPv4-in-IPv6 format. I know that we could insert more than two in_addr structures, but it is more complicated to handle. Also, I think it is important to have the flowlabels etc for IPv6 addresses, so we don't use in6_addr for locators. The port is defined twice; we could use the locator port to set the ESP-IN-UDP port number. The HIT takes 16 bytes. For future extensions purposes, I would actually suggest to take the "back-up" locator away and reuse its space with 16 bytes of reserved space just after the HIT. This way, we could have future expansion space for 256 bit HITs? And the single locator would fit nicely to the resolver scheme described above. What about datagram oriented communications? What should happen when the HIT and socket remain the same, but locator changes between two sendto() calls? I guess it could be used for enforcing an handover. There also some other protocols around with their own socket address structures (un, ipx, atmpvc, ax25, irda, rose, tipc, ash, ec). Perhaps it would be more wiser to fix IPv6 format at the API layer and define the sinh_loc just as an generic sockaddr. Does this make sense? I guess this is getting quite specific already, so it may be a better idea to move the discussion to HIP mailing lists? -- Miika Komu http://www.iki.fi/miika/
- sockets APIs extensions for Host Identity Protocol Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Stephane Bortzmeyer
- Re: sockets APIs extensions for Host Identity Pro… Chris Newman
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Stephane Bortzmeyer
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… Stephane Bortzmeyer
- Re: sockets APIs extensions for Host Identity Pro… Stephane Bortzmeyer
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- RE: sockets APIs extensions for Host Identity Pro… Henderson, Thomas R
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Tony Finch
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- RE: sockets APIs extensions for Host Identity Pro… Chris Newman
- Re: sockets APIs extensions for Host Identity Pro… Chris Newman
- Re: sockets APIs extensions for Host Identity Pro… Chris Newman
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Tony Finch
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… Keith Moore
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… Tony Finch
- Re: sockets APIs extensions for Host Identity Pro… der Mouse
- Re: sockets APIs extensions for Host Identity Pro… Miika Komu