Subject: [Hipsec] Review of draft-ietf-hip-native-api-02.txt

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Sep 2007 15:33:34 +0200

I have reviewed draft-ietf-hip-native-api-02.txt, and I think the 
documents is in good shape. 

I have however a couple of comments and suggested changes below that I 
would like to see addressed before the document is sent to IESG for 
publication. 

I had no time to distinguish between editorial and technical ones, 
sorry.

--julien
        
> Native Application Programming Interfaces for SHIM APIs
>              draft-ietf-hip-native-api-02

The title seems redundant. Shouldn't it be something like:

Native Application Programming Interfaces (API) for SHIM Layer 
Protocols.

> Abstract
>
> This document defines extensions to the current networking APIs

s/networking APIs/socket API/

> for protocols based on identifier/locator split.  Currently, the

s/based on/realizing an/
s/split/split (so called SHIM layers).

> document focuses on HIP, but the extensions can be used also by other
> protocols implementing identifier locator split.  Using the API

s/implementing identifier locator/realizing an identifier\/locator/
s/API/socket API/

> extensions, new SHIM aware applications can configure manually

SHIM aware should be explained. Maybe reword in:

...extensions, applications aware of the identifier/locator split 
(SHIM-aware applications) can manually configure...

> mappings between upper layer identifiers and the corresponding 
> locators.  Also, the API describes how to handle outbound

s/Also, the API/The API also/

> connection establishment where an application is unaware of the peer
> identifier but knows the peer locator.

Suggest adding '(Opportunistic Mode)' before the period ending the 
sentence.

> 1.  Terminology
>
> +---------+---------------------------------------------------------+
> | Term    | Explanation                                             |
> +---------+---------------------------------------------------------+
> | ULID    | Upper Layer IDentifier equals to the identity part of   |
> |         | the identity/locator split. It is the identifier used   |
> |         | by the application to name a peer for the transport     |
> |         | layer.                                                  |
> | Locator | Non-routable IPv4 or IPv6 address used at the lower     |
> |         | layers                                                  |
> | FQDN    | Fully Qualified Domain Name                             |
> | HIT     | Host Identity Tag, a 100-bit hash of a public key with  |
> |         | a 28 bit prefix                                         |
> | LSI     | Locally Scope Identifier, a 32-bit local presentation   |
> |         | of a public key                                         |
> +---------+---------------------------------------------------------+

s/Locally Scope Identifier/Local Scope Identifier/

> 2. Introduction
>
> Host Identity Protocol proposes a new cryptographic namespace and a

s/Host Identity Protocol/The Host Identity Protocol (HIP)/

> new layer to the TCP/IP architecture.  Applications can see these
> new changes in the networking stacks with varying degrees of
> visibility. [I-D.henderson-hip-applications] discusses the lowest
> levels of visibility in which applications are either unaware of HIP.
> The HIP- unaware applications use LSIs or HITs instead of IPv4 or IPv6

s/The HIP-unaware/HIP unaware/

> addresses.  Such applications may be unaware of the locator bindings.

s/the locator/identifier-locator/

> This document discusses about visibility of HIP to HIP-aware

s/discusses about/discusses/

> applications.  The applications are completely HIP aware and can

s/The applications/Such applications/

> control the HIP layer and Host Identifiers.  This document defines
> C-based sockets API extensions for handling the bindings
> explicitly.

s/the bindings/identifier-locator bindings/

> The extensions expose the identity-locator split to 
> SHIM-aware applications and it is up to the application, or a higher

SHIM and SHIM-aware are not defined in the introduction. At minimum I 
would expect the abstract text explaining the HIP focus but larger 
applicability to other SHIM layers to be duplicated here.

> level programming language, to manage the identities and locators.

s/the identities and locators/identifier-locator bindings/

> The API extensions introduce a new socket address structure.  The
> structure requires a new address family, PF_SHIM, for sockets that
> use HITs and locators explicitly.

Suggest rewording into:

The API extensions introduce a new address family, PF_SHIM, and a new 
socket address structure for sockets using explicits identifier-locator 
bindings.

Also, if we talk about address family, shouldn't we use AF_SHIM instead 
of PF_SHIM?

> An application can also use the family to detect SHIM support in the
> local host. 

Explain how, e.g. "the socket() call will fail (return -1) and set errno  
to EAFNOSUPPORT if the implementation does not support the specified 
address family."

> Hosts may accept incoming or initiate outgoing communications
> without the knowledge of the identity of the peer.

s/the identity of the peer/their peer identity/

Also, is "initiate outgoing communications without knowledge of the peer 
identity" opportunistic mode? If yes it should be spelled out. I don't 
see how it is possible to accept a HIP incoming communication without 
knowledge of the peer identity since identity will be in I2... Maybe 
you refer to initiate outgoing communications without knowing the local 
identity?

> This document describes also how to address this situation using late
> binding based on new wildcards.

'late binding' is not defined. We can't expect anyone to understand what 
it means.

> There are two related IETF documents that are define other related
> API extensions.  Multihoming related APIs are defined in
> [I-D.ietf-shim6-multihome-shim-api].  IPsec related policy
> attributes and channel bindings are defined in [I-D.ietf-btns-c-api]

I disagree with the use of 'other related API extensions' in this 
context. While this document does indeed defines extensions to the 
socket API, that is not true of the IPsec API [I-D.ietf-btns-c-api].

> 3.  Design Model
>
>
>    In this section, the native SHIM API design is described from an

s/from an/from a/

>    design point of view.  We describe the layering and namespace
> model. We conclude the discussion with a description of the resolver

s/model/models/

> model.
>
>
> 3.1.  Layering Model
>
>
>    The application layer accesses the transport layer via the socket
>    interface.  The application layer uses the traditional TCP/IP IPv4
> or IPv6 interface, or the new native SHIM API interface provided by
> the socket layer.  The layering model is illustrated in Figure 1. 
> For simplicity, the IPsec layer has been excluded from the figure.
>
>                          +--------------------------------+
>       Application Layer  |           Application          |
>                          +----------+----------+----------+
>            Socket Layer  | IPv4 API | IPv6 API | SHIM API |
>                          +----------+----+-----+----------+
>         Transport Layer  |      TCP      |      UDP       |
>                          +---------------+----------------+
>               SHIM Layer |       HIP and other SHIMs      |
>                          +---------------+----------------+
>           Network Layer  |     IPv4      |     IPv6       |
>                          +---------------+----------------+
>              Link Layer  |   Ethernet    |     Etc        |
>                          +---------------+----------------+
>
>                                  Figure 1
>
>    The SHIM layer is as a shim/wedge layer between the transport and
>    network layers.  The datagrams delivered between the transport and
>    network layers are intercepted in the SHIM layer to see if the
>    datagrams are SHIM related and require SHIM intervention.
>
>
> 3.2.  Namespace Model
>
>
>    The namespace model is shown in Table 2 from SHIM point of view. 
> The namespace identifiers are described in this section.
>
>               +-------------------+-------------------------+
>               | Layer             | Identifier              |
>               +-------------------+-------------------------+
>               | User Interface    | FQDN                    |
>               | Application Layer | ULID, port and protocol |
>               | Transport Layer   | ULID, port              |
>               | SHIM Layer        | ULID                    |
>               | Network Layer     | Locator                 |
>               +-------------------+-------------------------+
>
>                                   Table 2
>
>    User interfaces input human-readable names and translate them to
>    machine-readable names.  

human readable names are not limited to FQDNs, unqualified DNS names can 
be used too (e.g. thanks to the 'search example.com' line in 
a /etc/resolv.conf). I'm also not sure about restricting user 
interfaces to human-readable names (e.g. FQDN), it also happens that IP 
addresses are entered in user interface, alone or embedded in a URL. 

>    In SHIM API, the ULID is a HIT when the 
>    underlying protocol is HIP.  The ULID is present at the
> application layer and also transport layer checksum is calculated

s/and also/, and/

> based on it. The SHIM layer handles also ULIDs and translates them
> locators for the network layer.
>
>
> 3.3.  Interaction with the Resolver
>
>
>    Before an application can establish network communications, it
> must translate a hostname to the corresponding identifier(s).  DNS

Again, this is IMHO too restrictive. I suggest rewording into:

Before an application can establish network communications with the 
entity named by a given FQDN, it must translate that name into the 
corresponding identifier(s).  DNS...

> based hostname-to-identifier translation is illustrated in Figure 2. 
> The application calls the resolver (step a.) to resolve an FQDN (step
> b.).  The DNS server responds with ULIDs and a set of locators (step
> c.).  The resolver may not directly pass the ULIDs and the locators
> to the application, but may first inform to the SHIM module (steps d.
> and e.).  Finally, the resolver passes the ULIDs and locators to the
> application (step f.).
>
>                                   +----------+
>                                   |   DNS    |
>                                   +----------+
>                                       ^  |
>                             b. <FQDN> |  | c. <ULIDs + locators>
>                                       |  v
>        +-------------+ a. <FQDN>  +----------+
>        |             |----------->|          |
>        |
>        | Application |            | Resolver |
>        |
>        |             |<-----------|          |
>        +-------------+  f. <U+L>  +----------+
>                                       ^  |
>                              e. <U+L> |  | d. <U+L>
>                                       |  v
>                                   +----------+
>                                   |   SHIM   |
>                                   +----------+
>
>                                  Figure 2
>
>    In practise, the resolver functionality can implemented in

s/practise/practice/

> different ways.  It may be implemented in existing resolver libraries
> or as an DNS proxy.

s/an DNS/a DNS/

> 4.  API Syntax and Semantics
>
>
>    In this section, we describe the native SHIM API using the syntax
> of the C programming language and present only the ``external''
> interfaces and data structures that are visible to the applications.

I don't think the last part of the sentence is necessary ("present only 
the ``external''interfaces and data structures that are visible to the 
applications.") since this is the definition of an API. Suggest 
deleting it.

> We limit the description to those interfaces and data structures that
> are either modified or completely new, because the SHIM API is
> otherwise identical to the sockets API [POSIX].

In all API definitions that follows, it should be specified which header 
file should be included to result in the definitions (e.g. PF_SHIM,  
AF_SHIM, sockaddr_shim), e.g. <netinet/shim.h>, <netinet/in.h> or 
<netdb.h>. It would also be good to have a section that recapitulate 
all new definitions at the end of the document.

> 4.1.  Socket Family and Address Structure

In this section, w.r.t. to usage of SHIM_ANY* macros, I think using 
_source_ vs. _destination_ (or local vs. peer) to characterize the use 
of sockaddr_shim structures would be more to the point than referring 
to client vs. server applications -- sometimes, client applications 
bind(), and server connect()/sendto().

>    We introduce a new protocol family, PF_SHIM, for the sockets API.

Suggest completing the sentence into:

We introduce a new protocol family, PF_SHIM, and a new address family, 
AF_SHIM, for the sockets API.

>    The AF_SHIM constant is an alias for PF_SHIM.  The use of the
> PF_SHIM constant is mandatory with the socket() function if the SHIM
> API is to be used in the application.  The PF_SHIM constant is given
> as the first argument (domain) to the socket() function.
>
>    The ULIDs and locators are contained in the sockaddr_shim
> structure, which is shown in Figure 3.  The family of the socket,
> shim_family, is set to PF_SHIM.  The port number sins_port is two
> octets and the sins_ulid is four octets.  The ULID value is an IPv6
> address.  The locator is an IPv6 address or IPv6-mapped address IPv4

s/IPv6-mapped address/IPv6-mapped/

> address as defined in - [RFC3493].  The family is stored in host byte
> order and the ULID and locator are stored in network byte order.

Since family is the size of a byte, I think specifying that "the family 
is stored in host byte order" is a no-op.

>          typedef struct in6_addr shim_ulid_t;
>          typedef struct in6_addr shim_locator_t;
>
>          struct sockaddr_shim {
>                  uint8_t        sins_len;
>                  uint8_t        sins_family;
>                  uint16_t       sins_port;
>                  shim_ulid_t    sins_ulid;
>                  shim_locator_t sins_locator;
>                  uint64_t       sins_flags;
>          }

FWIW, some "logic" might lead to wonder about the choice of the sins_ 
prefix for fields of the sockaddr_shim structure:

sockaddr_in -> sin_len, sin_family, etc.
sockaddr_in6 -> sin6_len, sin6_family, etc.

Therefore:

sockaddr_shim -> sshim_len, sshim_family, etc.

>    The application usually sets the sins_ulid field using the
> resolver. However, three special macros can be used to directly set a
> value into the sins_ulid field.  The macros are SHIM_ANY,
> SHIM_ANY_PUB and SHIM_ANY_ANON.  They denote an ULID value associated
> with a wildcard ULID of any, public, or anonymous type.

I miss the definition of these different ULID types (public vs. 
anonymous). I think we need some more text or a reference to another 
document (e.g. RFC3041 privacy addresses used as 'anonymous' SHIM6 
ULID's).

>    In server applications, the SHIM_* macros accept incoming

s/SHIM_* macros accept/SHIM_ANY* macros allows accepting/

> connections to all of the ULID of the local host.  The macros
> correspond to the sockets API macros INADDR_ANY and IN6ADDR_ANY_INIT,
> but they are applicable at the SHIM layer.  It should be noticed that
> only one process at a time in a host can bind with the SHIM_*ANY

s/bind with the SHIM_*ANY/bind to the SHIM_ANY*/

> macro to the same port to avoid ambiguous bindings.

I'm not sure about the restriction to one host binding on a given port. 
There are TCP/IP stacks that allows binding multiple processes to bind 
to same addresses and/or ports through the use of the appropriate 
socket options (e.g. SO_REUSEADDR, SO_REUSEPORT); maybe we should cite 
them here, or remove the above restriction.

I am also not sure about restricting the above text to 'server 
application' -- client application might also bind sockets (e.g. FTP, 
although that's not the right exemple).

>    A client application can use the SHIM_ANY macro to establish a

s/macro to establish a/macro with connect() or sendto() calls/ 

>    connection when only the server locator (and not the ULID) is

s/connection/communication/

> known beforehand.
>    In both client and server based applications, the use of the
>    SHIM_ANY* macro accepts also non-SHIM based communications to
>    maximize backwards compatibility.  

The text should specify that goes into the sins_ulid field (e.g. zeroes) 
when that is the case.

>    When the application wants 
>    enforces the use of SHIM-based communications with ORCHID prefix
>    [RFC4843], it sets the flag SHIM_FLAG_ONLY_ORCHID in sins_flags.
>    Alternatively, the application accepts both ORCHID and non-ORCHID-
>    based communications, but informs the difference e.g. to the user.
>    In this case, the application calls SHIM_IPV6_ADDR_IS_ORCHID macro

How about SHIM_IS_IPV6_ADDR_ORCHID instead?

>    which inputs a pointer to a in6_addr and returns 1 when the
> address has orchid prefix and 0 otherwise.
>
>    Applications can also implement access control using the ULIDs. 
> In such a case, the application can compare two ULIDs using memcmp()
> or similar function.
>
> 4.2.  Resolver
>
>
>    The SHIM API uses the getaddrinfo resolver function which the
>    application uses to query both ULIDs and locators.  

I suggest to rewrite into:

The SHIM API introduces a new addrinfo flag, AI_SHIM, to be used by 
application to query for both ULID and locator information via the 
getaddrinfo() resolver function [RFC3493].
 
>    The resolver introduces a new data structure which is used both as
>    the input and output argument for the resolver.  The data structure
>    is illustrated in Figure 4.

s/The resolver introduces a new which is used both as the input an 
output argument for the resolver/The getaddrinfo() function uses a data 
structure used for both input to and output from the resolver/

>
>           struct addrinfo {
>               int    ai_flags;          /* e.g. AI_SHIM */
>               int    ai_family;         /* e.g. PF_SHIM */
>               int    ai_socktype;       /* e.g. SOCK_STREAM */
>               int    ai_protocol;       /* 0 or IPPROTO_HIP */
>               size_t ai_addrlen;        /* length of the endpoint */
>               struct sockaddr *ai_addr; /* socket address */
>               char   *ai_canonname;     /* canon. name of the host */
>               struct addrinfo *ai_next; /* next endpoint */
>           };
>
>                                  Figure 4
>
>    In addrinfo structures, the family field is set to PF_SHIM when
> the socket address structure contains an ULID that refers to ULID,

s/to ULID/to a ULID/

> such as HIT.

s/HIT/a HIT/

>    The flag AI_SHIM must be set, or otherwise the resolver does not
>    return sockaddr_shim data structures to guarantee that legacy
>    applications do not break.

But presumably legacy applications would not set ai_family to PF_SHIM, 
so the AI_SHIM flags seems redundant.

>    Some applications may prefer 
> configuring the locators manually and can set the AI_SHIM_NOLOCATORS
> flag to prohibit the getaddrinfo from resolving any locators.
>
>    The ai_family field is PF_SHIM with SHIM-specific addrinfo data
>    structures.

What is the "SHIM-specific addrinfo data structures" ? do you mean an 
addrinfo data structure with an ai_addr pointing to a sockaddr_shim 
data structure?

>    The protocol field is 0 when the getaddrinfo caller does not care
>    about the specific SHIM protocol to be used.  The caller (or the
>    resolver) can set this field also to IPPROTO_HIP.

s/protocol field/ai_protocol field/

Since this API is supposed to be usable for multiple SHIM protocols 
(e.g. HIP, SHIM6), for the resolver to know which SHIM protocol is in 
use I'd think that the caller MUST set the protocol field to the 
constant identifying the protocol in use (e.g. IPPROTO_HIP, 
IPPROTO_SHIM6).

>    ai_addrlen is the size of the structure pointed by ai_addr.

This is already specified as part of RFC3493. No need to duplicate that 
information here.

>    The ai_addr points to a sockaddr_shim structure when the value of
>    ai_family is PF_SHIM.  The resolver sets SHIM_RVS in sins_flags of
>    the when the locator belongs to a rendezvous server
>    [I-D.ietf-hip-dns].
>
>    The SHIM API does not introduce changes to the interface syntax of
>    the existing sockets API functions, such as bind(), connect(),
>    send(), sendto(), sendmsg(), recv(), recvfrom(), and recvmsg().

Same is true for for getaddrinfo(), BTW.

>    However, the SHIM-aware application usually passes the functions a
>    sockaddr_shim structure instead of a sockaddr_in or sockaddr_in6
>    structure.  A SHIM-aware application either creates the
> sockaddr_shim structures manually or obtains them from the resolver. 
> The getaddrinfo resolver [RFC3493] is shown in Figure 5.
>            int getaddrinfo(const char *nodename,
>                            const char *servname,
>                            const struct addrinfo *hints,
>                            struct addrinfo **res)
>            void free_addrinfo(struct addrinfo *res)
>
>                                  Figure 5
>
>    As described in [RFC3493], the getaddrinfo function takes the
>    nodename, servname, and hints as its input arguments.  It places
> the result of the query into the res argument.  The return value is
> zero on success, or a non-zero error value on error.  The nodename
> argument specifies the host name to be resolved; a NULL argument
> denotes the local host.  The servname parameter declares the port
> number to be set in the socket addresses in the res output argument.
> Both the nodename and servname cannot be NULL.
>
>    The input argument hints acts like a filter that defines the
>    attributes required from the resolved endpoints.  For example, the
>    resolver returns only anonymous endpoints in the output argument
> res when the application sets the ai_addr pointer of hints to point
> to a sockaddr_shim structure with sins_ulid filled with
> SHIM_ANY_ANON.  A NULL hints argument indicates that any kind of
> endpoints are acceptable.
>
>    The output argument res is dynamically allocated by the resolver.
>    The application must free res argument with the free_addrinfo
>    function.  

We do not need to specify that here, that's orthogonal to the discussion 
we're having IMO.

>    The res argument contains a linked list of the resolved 
>    endpoints.  The linked list contains sockaddr_shim structures only
>    when the input argument has the AI_SHIM flag set.  When the
> resolver finds SHIM identifiers, it inserts them to the front of the
> list.

This seems to imply that the resolver may also return non-SHIM sockaddr 
structures (e.g. sockaddr_in6) at the tail of the list. That should be 
made explicit.

>    Resolving of a hostname may result in multiple locators associated
> to a single ULID, but the sockaddr_shim structure contains only a
> single ULID-locator pair.  The resolver handles this by repeating the
> ULD as many time as needed.  For example, let us consider a case
> where the resolver finds an ULID that is associated to two locators. 
> In such a case, the resolver outputs two sockaddr_shim structures
> with the same ULID but different locators.
>
> 5.  IANA Considerations
>
>
>    No IANA considerations.
>
>
>
> 6.  Security Considerations
>
>    To be done.

Ditto. :-)

Hope the review helps.

--julien

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Miika Komu <[email-masked]>
Date: Wed, 12 Sep 2007 22:39:26 +0300 (EEST)

On Wed, 5 Sep 2007, Julien Laganier wrote:

Julien,

> would like to see addressed before the document is sent to IESG for

thanks for the review! I have addressed all of your editorial comments in 
the draft. A preversion of the next version of the draft based on your 
comments is in here:

http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre1.txt

> I had no time to distinguish between editorial and technical ones,

No problem.

Below I have commented only the things that were unclear or need further 
clarification, otherwise I applied your comments as you suggested. I see 
no need to repeat minor nits here.

> applicability to other SHIM layers to be duplicated here.

Added some text to intro, I hope the changes are fine.

> Also, if we talk about address family, shouldn't we use AF_SHIM instead

In practice, there is no difference between AF and PF. Added text:

    The API extensions introduce a new address family, AF_SHIM, and a new
    socket address structure for sockets using explicit identifier-
    locator bindings.  PF_SHIM is used as an alias for AF_SHIM in this
    document because the distinction between PF and AF has been lost in
    the practice.

> 'late binding' is not defined. We can't expect anyone to understand what

Removed 'late binding' since it was not really used elsewhere in the text. 
Changed the 'initiate outgoing' text to this:

    Some applications may accept incoming communications from any
    identifier.  Other applications may initiate outgoing communications
    without knowledge of the peer identifier in Opportunistic Mode
    [I-D.ietf-hip-base] by just relying on a peer locator.  This document
    describes how to address both situations using "wildcards" described
    in a later section.

> socket API, that is not true of the IPsec API [I-D.ietf-btns-c-api].

Changed to:

    There are two related API documents.  Multihoming related APIs are
    defined in [I-D.ietf-shim6-multihome-shim-api].  IPsec related policy
    attributes and channel bindings are defined in [I-D.ietf-btns-c-api]

> addresses are entered in user interface, alone or embedded in a URL.

I hope this is better then:

User Interface    | Hostname, FQDN or ULID

> all new definitions at the end of the document.

Added this, I hope it is ok now.

> document (e.g. RFC3041 privacy addresses used as 'anonymous' SHIM6

Added the reference as you suggested and added a reference HIP 
architecture RFC as well regarding to the anonymous bit. I hope this is 
ok? We could also removed the ANON and PUB altogether (I am referring to 
the discussion of Pekka and Philip on the anonymity topic).

> them here, or remove the above restriction.

Removed.

> s/macro to establish a/macro with connect() or sendto() calls/

Instead of listing all the socket calls, the text now says "outgoing 
communications". I hope this is ok to cover both TCP and UDP based 
communication?

> The text should specify that goes into the sins_ulid field (e.g. zeroes)

The SHIM_ANY macros is actually used to initialized that particular field. 
Clarified the text.

> How about SHIM_IS_IPV6_ADDR_ORCHID instead?

Agreed.

> ..
> ..

Removed the statement on removing legacy applications. I think the AI_SHIM 
flag is still necessary. The protocol field can be set to zero even with 
SHIM-aware applications when the application does not care which 
particular SHIM protocol it is riding on. In such a case, a separate flag 
is needed.

> addrinfo data structure with an ai_addr pointing to a sockaddr_shim

Yes, corrected.

> This is already specified as part of RFC3493. No need to duplicate that

I think it is more reader-friendly to go through all of the fields 
one-by-one and describe how they are affected by the draft. Added some 
clarifications:

    ai_addrlen is the size of the structure pointed by ai_addr.  This
    equals to sizeof(struct sockaddr_shim) when when ai_family field is
    PF_SHIM.

> We do not need to specify that here, that's orthogonal to the discussion

I think it is useful to recap here how the resolver works. Changed the 
text to:

    The output argument res is dynamically allocated by the resolver.
    The application frees res argument with the free_addrinfo function.
    The res argument contains a linked list of the resolved endpoints.
    The linked list contains sockaddr_shim structures only when the input
    argument has the AI_SHIM flag set.  When the resolver finds SHIM
    identifiers, it inserts them to the front of the list.  SHIM
    identifiers for different protocols are sorted according to local
    policies.  Non-SHIM identifiers are present only when ai_protocol is
    set zero in the hints arguments of getaddrinfo() or the hints
    argument is NULL.  The non-SHIM identifiers are placed after SHIM
    identifiers.

Notice: I added text that sorting e.g. between HIP vs. SHIM6 identifiers 
is a local policy issue.

> structures (e.g. sockaddr_in6) at the tail of the list. That should be

Done.

-- 
Miika Komu                                       http://www.iki.fi/miika/

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2007 13:48:07 +0200

Hi Miika,

On Wednesday 12 September 2007, Miika Komu wrote:
>
> thanks for the review! I have addressed all of your editorial
> comments in the draft. A preversion of the next version of the draft
> based on your comments is in here:
>

I found one more problem with the definition of LSI: It is not the 
presentation of a public key, but rather a 32-bit handle, or 
descriptor. Suggest to change the definition to:

    LSI : Local Scope Identifier, a local, 32-bit descriptor for a given 
          public key.

> Below I have commented only the things that were unclear or need
> further clarification, otherwise I applied your comments as you
> suggested. I see no need to repeat minor nits here.

All right. The updated draft looks good. Couple of followups below where 
more discussion is needed (I deleted the rest):

> > SHIM and SHIM-aware are not defined in the introduction. At minimum
> > I would expect the abstract text explaining the HIP focus but
> > larger applicability to other SHIM layers to be duplicated here.
>

I think that the following paragraph of the intro should also be 
duplicated in section 4 which specifies the API:

   An application can also use the new family to detect SHIM support in
   the local host.  Namely, the application creates a socket by calling
   socket() function with the first argument (domain) as AF_SHIM.  The
   system returns a positive integer representing a socket descriptor
   when the system supports SHIM.  Otherwise, the system returns -1 and
   sets errno to EAFNOSUPPORT.

> > human readable names are not limited to FQDNs, unqualified DNS
> > names can be used too (e.g. thanks to the 'search example.com' line
> > in a /etc/resolv.conf). I'm also not sure about restricting user
> > interfaces to human-readable names (e.g. FQDN), it also happens
> > that IP addresses are entered in user interface, alone or embedded
> > in a URL.
>

relative (i.e. not fully qualified) domain name are not necessarily 
limited to hostname, they can be any domain name taken relative to a 
well known origin, or to a list of domains used as a search list. For 
example, when the list of domain used as a search list 
contains "isi.edu." and "cs.isi.edu.", the fully qualified domain 
name "www.cs.isi.edu." corresponds to both of these relative domain 
name: "www" and "www.cs".

> >> We limit the description to those interfaces and data structures
> >> that are either modified or completely new, because the SHIM API
> >> is otherwise identical to the sockets API [POSIX].
> >
> > In all API definitions that follows, it should be specified which
> > header file should be included to result in the definitions (e.g.
> > PF_SHIM, AF_SHIM, sockaddr_shim), e.g. <netinet/shim.h>,
> > <netinet/in.h> or <netdb.h>. It would also be good to have a
> > section that recapitulate all new definitions at the end of the
> > document.
>

I checked it, and I am questioning the location of the "shim.h" header 
file. My understanding is that the SHIM layer will be used in 
cunjunction with an internet protocol. As such, my choice would be to 
put the "shim.h" header file in the "netinet/" subdirectory. That is 
replace <shim.h> with <netinet/shim.h>.

If the SHIM facility is expected to be used with network protocols other 
than internet ones, then I'd rather expect <net/shim.h>

What do you think?

> communications". I hope this is ok to cover both TCP and UDP based

I still think it is better to list the systems calls since it is not 
clear _where_ the macro is used if you just say "outgoing 
communications" -- is it used for bind() or connect() ?

> > The text should specify that goes into the sins_ulid field (e.g.
> > zeroes) when that is the case.
>
> The SHIM_ANY macros is actually used to initialized that particular
> field. Clarified the text.

The text has some typos, and misses 'also' at the beginning. Rewrite in:

   An application can also use the the SHIM_ANY macro in sshim_ulid
   field to establish outgoing communications in Opportunistic mode 
   [I-D.ietf-hip-base], when the application knows the remote peer
   locator but no ULID.

Another typo:

s/The SHIM_ANY* macro/The SHIM_ANY* macros/ 

That's it.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2007 13:48:07 +0200

Hi Miika,

What do you think?

Another typo:

That's it.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2007 13:48:07 +0200

Hi Miika,

What do you think?

Another typo:

That's it.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2007 13:48:07 +0200

Hi Miika,

What do you think?

Another typo:

That's it.

--julien

---

From: Miika Komu <[email-masked]>
Date: Sun, 16 Sep 2007 22:36:19 +0300 (EEST)

On Thu, 13 Sep 2007, Julien Laganier wrote:

Hi Julien,

new version based on your comments is available here:

http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre2.txt

>    LSI : Local Scope Identifier, a local, 32-bit descriptor for a given

Ok.

>   sets errno to EAFNOSUPPORT.

Added.

> name: "www" and "www.cs".

Please make a concrete suggestion on what to change? I think this not very 
important for the draft.

> than internet ones, then I'd rather expect <net/shim.h>

Changed it to <netinet/shim.h>.

> communications" -- is it used for bind() or connect() ?

Ok, added the examples.

> s/The SHIM_ANY* macro/The SHIM_ANY* macros/

Changed. Thanks for your feedback!

---

From: Miika Komu <[email-masked]>
Date: Sun, 16 Sep 2007 22:36:19 +0300 (EEST)

Hi Julien,

Ok.

Added.

Ok, added the examples.

---

From: Miika Komu <[email-masked]>
Date: Sun, 16 Sep 2007 23:05:07 +0300 (EEST)

Hi folks,

as you know the HIP-related API standards have been split into three 
different working groups:

* BTNS WG draft describes how to get/set ipsec related attributes and how
   to control channel bindings in an IPsec-aware application:
   http://www.ietf.org/internet-drafts/draft-ietf-btns-c-api-01.txt
* SHIM6 WG draft explains how to get/set multihoming related attributes
   (such as locator management) in a SHIM6/HIP aware application:
   http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-03.txt
* HIP WG draft describes initial identity-locator discovery and the
   use of opportunistic mode in a HIP-aware application:
   http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-03-pre2.txt

I got feedback from Shinta who is the editor of the SHIM6 API draft. Below 
is a summary of the discussion so far:

* The name of the native HIP API draft is not very descriptive anymore? I
   suggested "Sockets API Extensions for Initial Discovery  and Management
   of SHIM Layer Identifier-locator Bindings", since SHIM6  draft already
   takes care of locator bindings especially after the initial contact.
   Please suggest if you can think of some better name.
* Is the native API draft useful for SHIM6 at all? I am looking for
   more feedback on this, but I have the following use case in my mind: an
   application that is both HIP and SHIM6 aware. Even though the native HIP
   API draft is not very useful for SHIM6, we should guarantee
   interoperability between the two protocols at the API level.

---

From: Miika Komu <[email-masked]>
Date: Sun, 16 Sep 2007 23:05:07 +0300 (EEST)

Hi folks,

---

From: Jan Mikael Melen <[email-masked]>
Date: Mon, 17 Sep 2007 11:49:08 +0300

Hello,

Question regarding section 4.1.  Socket Family and Address Structure. 
Why there is sshim_locator in the sockaddr_shim?
         struct sockaddr_shim {
                 uint8_t        sshim_len;
                 uint8_t        sshim_family;
                 uint16_t       sshim_port;
                 shim_ulid_t    sshim_ulid;
                 shim_locator_t sshim_locator;
                 uint64_t       sshim_flags;
         }

IMHO it is not needed as the connection to peer is bound to ULID not 
locator and the peer might have more than one locator which means that 
you are not anyway providing full set of locators to the socket. 
Furthermore in section 3.3 the resolver is supposed to deliver both 
ULIDs and locators to the SHIM layer.

    Jan

Miika Komu wrote:
> thanks for the review! I have addressed all of your editorial comments 
> in the draft. A preversion of the next version of the draft based on 
> your comments is in here:
>
> Removed 'late binding' since it was not really used elsewhere in the 
> text. Changed the 'initiate outgoing' text to this:
>
> architecture RFC as well regarding to the anonymous bit. I hope this 
> is ok? We could also removed the ANON and PUB altogether (I am 
> referring to the discussion of Pekka and Philip on the anonymity topic).
>
> Removed the statement on removing legacy applications. I think the 
> AI_SHIM flag is still necessary. The protocol field can be set to zero 
> even with SHIM-aware applications when the application does not care 
> which particular SHIM protocol it is riding on. In such a case, a 
> separate flag is needed.
>
> Notice: I added text that sorting e.g. between HIP vs. SHIM6 
> identifiers is a local policy issue.
>

---

From: Miika Komu <[email-masked]>
Date: Mon, 17 Sep 2007 14:49:06 +0300 (EEST)

On Mon, 17 Sep 2007, Jan Mikael Melen wrote:

Hi,

ulid is the HIT and locator is a routable address (IPv4 or IPv6). The 
legacy API draft discusses in detail the case where only HITs are given to 
a non-HIP aware application.

Due to constraints in the resolver API and size of sockaddr structures, 
the returned data structures may contain some redundancy. Particularly, 
the resolver returns n * m sockaddr_shim data structures when the 
resolution results in n HITs and m locators.

Returning multiple locators within a single sockaddr structure is 
possible, but the sockaddr structure size is limited and we have to 
have some redundancy anyway. The resolution procedure also considers 
mostly *initial* address look-up from DNS. The hosts are free to 
communicate additional locators in the base exchange or using UPDATE.

On the other hand, multiple locators in a single structure might speed-up 
the HIP connection establishment when the base exchange is parallerized. 
However, some applications parallize connections already at the 
application layer. I have no strong opinion on this. We can fit easily fit 
10 in6_addr locator structures into sockaddr_shim. Opinions?

> Hello,
>
> Question regarding section 4.1.  Socket Family and Address Structure. Why 
> there is sshim_locator in the sockaddr_shim?
>        struct sockaddr_shim {
>                uint8_t        sshim_len;
>                uint8_t        sshim_family;
>                uint16_t       sshim_port;
>                shim_ulid_t    sshim_ulid;
> IMHO it is not needed as the connection to peer is bound to ULID not locator 
> and the peer might have more than one locator which means that you are not 
> anyway providing full set of locators to the socket. Furthermore in section 
> 3.3 the resolver is supposed to deliver both ULIDs and locators to the SHIM 
> layer.
>
>   Jan
>
>
> Miika Komu wrote:
>> clarification, otherwise I applied your comments as you suggested. I see no 
>> need to repeat minor nits here.
>> 
>> Added the reference as you suggested and added a reference HIP architecture 
>> RFC as well regarding to the anonymous bit. I hope this is ok? We could 
>> also removed the ANON and PUB altogether (I am referring to the discussion 
>> of Pekka and Philip on the anonymity topic).
>> 
>> SHIM-aware applications when the application does not care which particular 
>> SHIM protocol it is riding on. In such a case, a separate flag is needed.
>>
>> I think it is useful to recap here how the resolver works. Changed the text 
>> to:
>>
>> Notice: I added text that sorting e.g. between HIP vs. SHIM6 identifiers is 
>> a local policy issue.
>>

---

From: Julien Laganier <[email-masked]>
Date: Mon, 17 Sep 2007 13:58:02 +0200

Hi Miika,

I checked it, looks good. Only remaining item is:

> >>> names can be used too (e.g. thanks to the 'search example.com'
> >>> line in a /etc/resolv.conf). I'm also not sure about restricting
> >>> user interfaces to human-readable names (e.g. FQDN), it also
> >>> happens that IP addresses are entered in user interface, alone or
> >>> embedded in a URL.
> >>
> > limited to hostname, they can be any domain name taken relative to
> > a well known origin, or to a list of domains used as a search list.
> > For example, when the list of domain used as a search list
> Please make a concrete suggestion on what to change? I think this not
> very important for the draft.

s/hostname/relative domain name/

--julien

---

From: Jan Mikael Melen <[email-masked]>
Date: Mon, 17 Sep 2007 15:33:42 +0300

Hi,

I don't understand the reasoning behind the logic why would we want to 
have the locator in the first place in the sockaddr_shim. Now the 
current daft suggests  that if the application resolves peer's FQDN 
using hints AF_UNSPEC it will end up getting a struct sockadd_shim which 
contains the locator for the peer and addition to that you will get 
sockaddr_in/in6 which also contains locator to the peer. E.g. now if the 
peer has one (1) ipv4 address and two (2) ipv6 addresses and ulid the 
result as said in the current draft is 3 x sockaddr_shim, 2 x 
sockaddr_in6, 1 x sockaddr_in.

Semantically I would expect that it would work as today. So my 
understanding is that if application resolves the FQDN using hints 
AF_INET it will get a list of ipv4 addresses and if using AF_INET6 the 
application will get the list of ipv6 addresses. If I now draw a line 
from this to the AF_SHIM, I would expect to get only a list of ULIDs 
that the peer has because as an application I'm not really interested of 
the locator anymore (that is the whole point of of having shim layer). 
Maybe I have missed something.

If then again I would be a application that is interested both from 
ulids and addresses I would then give hints AF_UNSPEC which would then 
result a list containing sockaddr_shim, sockaddr_in, sockaddr_in6 
addresses. None of the structs would contain duplicated data, if we take 
again the same example as earlier we would get 1 x sockaddr_shim, 2 x 
sockaddr_in6, 1 x sockaddr_in.

   Regards,
     Jan

Miika Komu wrote:
> legacy API draft discusses in detail the case where only HITs are 
> given to a non-HIP aware application.
>
> Due to constraints in the resolver API and size of sockaddr 
> structures, the returned data structures may contain some redundancy. 
> Particularly, the resolver returns n * m sockaddr_shim data structures 
> when the resolution results in n HITs and m locators.
>
> On the other hand, multiple locators in a single structure might 
> speed-up the HIP connection establishment when the base exchange is 
> parallerized. However, some applications parallize connections already 
> at the application layer. I have no strong opinion on this. We can fit 
> easily fit 10 in6_addr locator structures into sockaddr_shim. Opinions?
>
>> Hello,
>>
>> locator and the peer might have more than one locator which means 
>> that you are not anyway providing full set of locators to the socket. 
>>>> names can
>>>> that IP
>>>> header
>>> AI_SHIM flag is still necessary. The protocol field can be set to 
>>> zero even with SHIM-aware applications when the application does not 
>>> care which particular SHIM protocol it is riding on. In such a case, 
>>> a separate flag is needed.
>>>
>>> one-by-one and describe how they are affected by the draft. Added 
>>> some clarifications:
>>>
>>> I think it is useful to recap here how the resolver works. Changed 
>>> the text to:
>>>

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Sep 2007 10:29:59 +0300 (EEST)

On Mon, 17 Sep 2007, Julien Laganier wrote:

Hi Julien,

> s/hostname/relative domain name/

Thanks, this change will be in the next version.

_______________________________________________
HipseFrom [email-masked] Tue Sep 18 03:30:39 2007
Date: Tue, 18 Sep 2007 10:29:59 +0300 (EEST)
From: Miika Komu <[email-masked]>
To: Julien Laganier <[email-masked]>
Subject: Re: [Hipsec] Review of draft-ietf-hip-native-api-02.txt
Cc: 'HIP WG' <[email-masked]>, [email-masked]

On Mon, 17 Sep 2007, Julien Laganier wrote:

Hi Julien,

> s/hostname/relative domain name/

Thanks, this change will be in the next version.

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Sep 2007 10:30:03 +0300 (EEST)

Hi Jan,

> Hi,
>
> I don't understand the reasoning behind the logic why would we want to have 
> the locator in the first place in the sockaddr_shim. Now the current daft 
> suggests  that if the application resolves peer's FQDN using hints AF_UNSPEC 
> it will end up getting a struct sockadd_shim which contains the locator for 
> the peer and addition to that you will get sockaddr_in/in6 which also 
> contains locator to the peer. E.g. now if the peer has one (1) ipv4 address 
> and two (2) ipv6 addresses and ulid the result as said in the current draft 
> is 3 x sockaddr_shim, 2 x sockaddr_in6, 1 x sockaddr_in.
>
> Semantically I would expect that it would work as today. So my understanding 
> is that if application resolves the FQDN using hints AF_INET it will get a 
> list of ipv4 addresses and if using AF_INET6 the application will get the 
> list of ipv6 addresses. If I now draw a line from this to the AF_SHIM, I 
> would expect to get only a list of ULIDs that the peer has because as an 
> application I'm not really interested of the locator anymore (that is the 
> whole point of of having shim layer). Maybe I have missed something.

I got your point now. You just want the ulid field and not the locator 
field. You are also implicitly suggesting that the resolver (or local DNS 
proxy) communicates the IP addresses matching to the HIP daemon as a side 
effect of HIT resolving as ic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Sep 2007 10:30:03 +0300 (EEST)

Hi Jan,

I got your point now. You just want the ulid field and not the locator 
field. You are also implicitly suggesting that the resolver (or local DNS 
proxy) communicates the IP addresses matching to the HIP daemon as a side 
effect of HIT resolving as in the legacy API draft. I guess you would 
solve the problem of manually configured HIT-to-IP mappings with 
setsockopt as in sections 5.6. or 5.10 of the SHIM6 API draft, right?

Having a single ULID field would perhaps be more aligned with SHIM6. On 
the other hand, the locator field could be just zeroes in this case.

How would you suggest to handle the opportunistic mode? Would you just 
replace the ULID in sockaddr_shim with a routable IPv6 address? And 
perhaps a hint for the resolver to automatize this procedure. However, 
then we would end up again with redundantly routable addresses in the 
list.

Having both ULID and locator fields has the drawback of exposing the 
application to a possibly outdated locator. Neverthless, this was 
preferred in the applications area. They felt that we should define a low 
level API that exposes everything to the application or higher level 
network programming library. The HIT-IP mappings should not be hidden from 
the application:

http://www1.ietf.org/mail-archive/web/discuss/current/msg00533.html
http://www1.ietf.org/mail-archive/web/discuss/current/msg00520.html
http://www1.ietf.org/mail-archive/web/discuss/current/msg00546.html
http://www1.ietf.org/mail-archive/web/discuss/current/msg00537.html
http://www1.ietf.org/mail-archive/web/discuss/current/msg00497.html

> If then again I would be a application that is interested both from ulids and 
> addresses I would then give hints AF_UNSPEC which would then result a list 
> containing sockaddr_shim, sockaddr_in, sockaddr_in6 addresses. None of the 
> structs would contain duplicated data, if we take again the same example as 
> earlier we would get 1 x sockaddr_shim, 2 x sockaddr_in6, 1 x sockaddr_in.

I have no strong objection against this, but it seems to conflict slightly 
with the apps area folks views. The original idea of "endpoint descriptor" 
was discarded because apps area folks wanted to expose everything to the 
applications.

I used the word "slightly" because it is still possible to do manual 
locator handling in the application. If the application has only a single 
ULID field and not locator field in sockaddr_shim, the application can 
still query for the locators using a getsockopt() even before doing the 
actual connection, It could even call setsockopt() to overwrite the 
default peer locator before initial contact. I believe this would be more 
aligned with the SHIM6 API draft.

If there are no strong objections, we can go towards Jan's approach. It 
just a matter whether we expose things in already in getaddrinfo() or 
later in socket options. I'd appreciate comments from other folks as well.

n the legacy API draft. I guess you would 
solve the problem of manually configured HIT-to-IP mappings with 
setsockopt as in sections 5.6. or 5.10 of the SHIM6 API draft, right?

Having a single ULID field would perhaps be more aligned with SHIM6. On 
the other hand, the locator field could be just zeroes in this case.

How would you suggest to handle the opportunistic mode? Would you just 
replace the ULID in sockaddr_shim with a routable IPv6 address? And 
perhaps a hint for the resolver to automatize this procedure. However, 
then we would end up again with redundantly routable addresses in the 
list.

Having both ULID and locator fields has the drawback of exposing the 
application to a possibly outdated locator. Neverthless, this was 
preferred in the applications area. They felt that we should define a low 
level API that exposes everything to the application or higher level 
network programming library. The HIT-IP mappings should not be hidden from 
the application:

http://www1.ietf.org/mail-archive/web/discuss/current/msg00533.html
http://www1.ietf.org/mail-archive/web/discuss/current/msg00520.html
http://www1.ietf.org/mail-archive/web/discuss/current/msg00546.html
http://www1.ietf.org/mail-archive/web/discuss/current/msg00537.html
http://www1.ietf.org/mail-archive/web/discuss/current/msg00497.html

> If then again I would be a application that is interested both from ulids and 
> addresses I would then give hints AF_UNSPEC which would then result a list 
> containing sockaddr_shim, sockaddr_in, sockaddr_in6 addresses. None of the 
> structs would contain duplicated data, if we take again the same example as 
> earlier we would get 1 x sockaddr_shim, 2 x sockaddr_in6, 1 x sockaddr_in.

I have no strong objection against this, but it seems to conflict slightly 
with the apps area folks views. The original idea of "endpoint descriptor" 
was discarded because apps area folks wanted to expose everything to the 
applications.

I used the word "slightly" because it is still possible to do manual 
locator handling in the application. If the application has only a single 
ULID field and not locator field in sockaddr_shim, the application can 
still query for the locators using a getsockopt() even before doing the 
actual connection, It could even call setsockopt() to overwrite the 
default peer locator before initial contact. I believe this would be more 
aligned with the SHIM6 API draft.

If there are no strong objections, we can go towards Jan's approach. It 
just a matter whether we expose things in already in getaddrinfo() or 
later in socket options. I'd appreciate comments from other folks as well.

---

From: Jan Mikael Melen <[email-masked]>
Date: Tue, 18 Sep 2007 13:33:07 +0300

Hi,

See inline....

On Tuesday 18 September 2007 10:30, Miika Komu wrote:
> > have the locator in the first place in the sockaddr_shim. Now the current
> > daft suggests  that if the application resolves peer's FQDN using hints
> > AF_UNSPEC it will end up getting a struct sockadd_shim which contains the
> > locator for the peer and addition to that you will get sockaddr_in/in6
> > which also contains locator to the peer. E.g. now if the peer has one (1)
> > ipv4 address and two (2) ipv6 addresses and ulid the result as said in
> > the current draft is 3 x sockaddr_shim, 2 x sockaddr_in6, 1 x
> > sockaddr_in.
> >
> > from this to the AF_SHIM, I would expect to get only a list of ULIDs that
> > the peer has because as an application I'm not really interested of the
> > locator anymore (that is the whole point of of having shim layer). Maybe
> > I have missed something.
>
> effect of HIT resolving as in the legacy API draft. 

You are already stating that in your draft in the figure 2 in section 3.3.

> I guess you would 

Yep, that is what I would expect that I would have to do if I'm a geek that 
does not use DNS or have some other weird application.

> replace the ULID in sockaddr_shim with a routable IPv6 address? 

This you can do as well with the setsockopt and then just give a empty 
sockaddr_shim to the connect and other calls. Probably you we were anyway 
planning to give a sockaddr_shim where the ulid is empty in the case of 
opportunistic mode?

> And 

As I said in the mail I have probably missed something :-) Still I don't fully 
agree with the application guys. I would like to keep the design clean and do 
the setsockopt stuff for the geek's that want to have some kind of control of 
the locator. IMHO I think that in the generic case the application couldn't 
care less about the actual locator of the host. In the generic case the 
application and the user is more interested to whom it is talking to rather 
than where the application/user is located.

Anyway, in case one of the peer hosts is mobile the HIT-IP mapping will hidden 
as soon as one of  the peer host's moves. Or in case where the peer send's 
UPDATE packet giving new preferred locator. Or are you planning to make some 
new API for feeding the HIT-IP mapping updates to the application?

> > If then again I would be a application that is interested both from ulids
> > and addresses I would then give hints AF_UNSPEC which would then result a
> > list containing sockaddr_shim, sockaddr_in, sockaddr_in6 addresses. None
> > of the structs would contain duplicated data, if we take again the same
> > example as earlier we would get 1 x sockaddr_shim, 2 x sockaddr_in6, 1 x
> > sockaddr_in.
>

  Regards,
     Jan

---

From: Miika Komu <[email-masked]>
Date: Tue, 18 Sep 2007 14:58:53 +0300 (EEST)

On Tue, 18 Sep 2007, Jan Mikael Melen wrote:

Hi,

> You are already stating that in your draft in the figure 2 in section 3.3.

Ah, good catch. The picture was based on older draft version. Anyway, I 
think I won't fix it until we resolve the issue locator vs. no locator 
issue.

I am currently puzzled on how to proceed due to conflicting feedback. 
Perhaps others should voice out their opinions?

> sockaddr_shim to the connect and other calls.

Works for me.

> Probably you we were anyway planning to give a sockaddr_shim where the 
> ulid is empty in the case of opportunistic mode?

Yes. Not really empty, but a ULID filled in with macro.

> As I said in the mail I have probably missed something :-) Still I don't 
> fully agree with the application guys. I would like to keep the design 
> clean and do the setsockopt stuff for the geek's that want to have some 
> kind of control of the locator. IMHO I think that in the generic case 
> the application couldn't care less about the actual locator of the host. 
> In the generic case the application and the user is more interested to 
> whom it is talking to rather than where the application/user is located.

True, especially in NATted environments.

> Anyway, in case one of the peer hosts is mobile the HIT-IP mapping will 
> hidden as soon as one of the peer host's moves. Or in case where the 
> peer send's UPDATE packet giving new preferred locator. Or are you 
> planning to make some new API for feeding the HIT-IP mapping updates to 
> the application?

See the SHIM6 API, section 6.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 18 Sep 2007 09:53:32 -0700

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Tuesday, September 18, 2007 4:59 AM
> To: Jan Mikael Melen
> Cc: 'HIP WG'

I would prefer Jan's suggestion because it seems cleaner/more explicit
from a semantics standpoint to not bundle the identifier and locator
into a giant sockaddr.  I understand what you are trying to do to avoid
requiring new socket calls or options, but I suspect it is not going to
work out cleanly in the end due to multihoming, mobility, and NAT, as
already mentioned.  Plus, it seems counter to the HIP philosophy of
shielding applications from having to know about locators (although I
think everyone would agree that there is a requirement to give
applications the option to specify locators if they want to).

The downside to splitting them is that it either requires new
setsockopts or new socket functions such as bindtoaddress() or
sendtoaddress() where the argument is explicitly a sockaddr_in.  Whether
the function to add locator lists to the socket is a setsockopt or a new
function call doesn't matter that much to me; I would be fine aligning
it with whatever develops on the shim6 side of things.

Regarding opportunistic mode, one could conceivably pass sockaddr_in6 in
the connect() or sendto() of a HIP socket.  That would probably work but
may be less safe (prone to programming errors) if that is not what was
really intended by the user.  It may be cleaner to devise a general
programming method that allows one to add, delete, and prioritize
addresses that are associated with the localname and peername (HITs) of
the socket, and use these calls everywhere, and just send to the
SHIM_ANY (or HOST_ANY) address as the sockaddr if the application wants
to invoke opportunistic mode.   

Conversely, one could also design extensions to the AF_INET-based
sockets to allow applications to use IP addresses at the socket calls
and to set socket options to also associate host identities with the
sockets, and use sockopt flags to invoke HIP.  

> application/user is located.

I think there is a distinction between exposing everything to the
applications and overloading the existing function calls or structures
to fit it all in within the existing set of functions.  I support the
former but I think it is better to do so by expanding the API.

Tom

---

From: Philip Matthews <[email-masked]>
Date: Tue, 18 Sep 2007 23:19:56 -0400

>
> If there are no strong objections, we can go towards Jan's  
> approach. It just a matter whether we expose things in already in  
> getaddrinfo() or later in socket options. I'd appreciate comments  
> from other folks as well.

I think that there could easily be two or more locators associated  
with a HIT with no easy way to tell which one is the "best" or  
"primary". Furthermore, when NATs are involved, a locator will also  
include a encapsulation (e.g., UDP) and a port number. Also, a group  
of us are also investigating ways of finding a HIT by searching for  
it in an overlay, which suggests that the locator might be an  
OverlayID or similar. Jeffrey Arhenholz seems to be investigating  
similar ideas. It seems that these options would not be easily  
accommodated in your socket structure, and this suggests that socket  
options might be the better way to go.

- Philip

---

From: Ari Keränen <[email-masked]>
Date: Tue, 25 Sep 2007 12:53:33 +0300

Hi,

> later in socket options. I'd appreciate comments from other folks as well.

I also agree with Jan and Philip that the socket options is a better way 
to do this. Yet, I think it is very important there is some (easy) way 
to define locators for HITs. Using HIT-locator pairs discovered from a 
P2P overlay is a good example where this kind of functionality is needed.

-Ari