Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-api-06

From: Ari Keranen <[email-masked]>
Date: Wed, 01 Jul 2009 13:27:34 +0300

Henderson, Thomas R wrote:
>> -----Original Message-----
>> From: Ari Keranen [mailto:[email-masked]] 
>> Sent: Tuesday, June 30, 2009 4:22 AM
>> To: HIP
>> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-api-06
>>
>> Gonzalo Camarillo wrote:
>>> we would like to start the WGLC on the following draft:
>>>
>>> http://tools.ietf.org/html/draft-ietf-hip-native-api-06
>> Here are some comments on the HIP native API draft. Indented text is 
>> copy-pasted from the draft.
>>
>> The draft does not seem to take NAT traversal into account. For NAT 
>> traversal purposes an application that is not using a 
>> resolver should be 
>> able to get the local UDP port used by the HIP daemon for receiving 
>> incoming HIP messages. Also the application should be able create a 
>> HIT-to-locator mapping that includes a (possibly 
>> non-standard) UDP port 
>> number for a peer. Probably this is more of an issue for the 
>> shim6 API 
>> draft, though.
> 
> I'm concerned that you have hit upon a real problem here.  The shim6
> draft or protocol framework do not seem to have any concept of NAT
> traversal support.  I do not think this is a simple patch for the shim6
> document; for instance, is shim6 WG willing to rewrite Figure 1 of
> http://www.ietf.org/internet-drafts/draft-ietf-shim6-multihome-shim-api-
> 08.txt
> to show the shim6 layer sitting on top of UDP?  The concept of a locator
> in shim6 is an IPv6 address, not a transport address.

True. Overall shim6 is really IPv6 centric, and even in the shim6 WG 
charter it's said that:

- IPv6 NAT devices are assumed not to exist, or not to present an
obstacle about which the shim6 solution needs to be concerned.
- Only IPv6 is considered.

So this could actually be quite a bit out of scope for the shim6 API draft.

> One possibility would be to remove the explicit locator-related messages
> in the native HIP API document (leaving them for further study), but
> that would also strip out the support for outbound opportunistic mode.
> 
> The other options seem to be to ask the shim6-api draft authors, and WG,
> to support NAT traversal, or to just write a HIP-specific API for these
> aspects.  In either case, I think we (HIP WG) should decide what we want
> this API to be.

Probably writing a HIP-specific API would be the easier way, but surely 
it doesn't hurt to ask from the shim6 API draft authors (and WG?) too.

Anyway, I think this is an important issue and should be addressed 
somehow. The NAT traversal related requirements for the API include at 
least:
- ability for an application to learn the local HIP UDP port number and 
IP address (so it can publish them e.g., to a DHT)
- ability for an application to set the port (in addition to IP address) 
for a peer locator when creating a HIT-locator mapping to the daemon

In addition, it would be helpful to have a way to store the port number 
to DNS, but I don't see this as important as the two requirements above.

Cheers,
Ari

---

From: Miika Komu <[email-masked]>
Date: Thu, 02 Jul 2009 13:58:22 +0300

Ari Keranen wrote:

Hi,

>>> From: Ari Keranen [mailto:[email-masked]] Sent: Tuesday, 
>>> June 30, 2009 4:22 AM
>>> To: HIP
>>> traversal purposes an application that is not using a resolver should 
>>> be able to get the local UDP port used by the HIP daemon for 
>>> receiving incoming HIP messages. Also the application should be able 
>>> create a HIT-to-locator mapping that includes a (possibly 
>>> non-standard) UDP port number for a peer. Probably this is more of an 
>>> issue for the shim6 API draft, though.
>>

Agree, but a problem is that the same API is used by two protocols. The 
SHIM API should be modular enough to accommodate both of them. At the 
minimum, the SHIM draft could define some reserved fields for ports to 
support further extensions.

> it doesn't hurt to ask from the shim6 API draft authors (and WG?) too.

We could increase the flexibility in the SHIM API for future extensions 
but I am not yet convinced for the need for applications to control the 
UDP port numbers in HIP API for the following reasons:

* The UDP port numbers would be mostly useful IMHO in a library based 
HIP implementation (e.g. OpenSSL extensions). So far, there has been 
little work towards this (albeit the specifications shouldn't create 
artificial obstacles for such work).
* We have decided earlier to exclude support for user specific HITs in 
the draft which are basically required for library-based implementations.
* The NAT draft doesn't really handle properly the case where a host has 
single HIT but uses multiple UDP ports.
* The current version of the HIP API is oriented towards DNS and not DHT 
(see related comment on the end of this email).

> IP address (so it can publish them e.g., to a DHT)

I believe you mean the relay reflexive address? I think publishing the 
IP address of the relay should suffice and this can be done at the 
system level.

> for a peer locator when creating a HIT-locator mapping to the daemon

Once again, the relay address should be sufficient. The port number is 
not necessary because a HIP relay uses HITs for demultiplexing traffic. 
The end-hosts negotiate the TURN relay dynamically during the base 
exchange. I think the TURN relay should be set also at the system level 
and not at the application layer to avoid user access control issues 
(which are not currently in the scope of the draft).

> to DNS, but I don't see this as important as the two requirements above.

The OpenDHT extensions can already support UDP port numbers. DNS 
extensions are not really in the scope of the API drafts apart from the 
resolver interface.

---

From: Ari Keranen <[email-masked]>
Date: Thu, 02 Jul 2009 14:46:09 +0300

Hi,

Miika Komu wrote:
>>>> traversal purposes an application that is not using a resolver 
>>>> should be able to get the local UDP port used by the HIP daemon for 
>>>> non-standard) UDP port number for a peer. Probably this is more of 
>>>> an issue for the shim6 API draft, though.
>>>

Sounds reasonable.

>> Probably writing a HIP-specific API would be the easier way, but 
>> surely it doesn't hurt to ask from the shim6 API draft authors (and 
>> WG?) too.
> 

Library based implementations are just one use case for this. For 
example, you could sit behind a NAT that allows nicely anyone to contact 
you, but you can't choose your public port number. Or some other service 
might be running on the HIP port, and thus HIP daemon needs to use some 
other port than what IANA reserves for the purpose.

> single HIT but uses multiple UDP ports.

How come? Anyway, I would consider using multiple UDP ports a bit corner 
case anyway.

> (see related comment on the end of this email).

That's true, but I think supporting also DHT-like environments would 
make sense. Or would you prefer a separate draft for that?

>> - ability for an application to learn the local HIP UDP port number 
>> and IP address (so it can publish them e.g., to a DHT)
> 

I mean what ever port & address you use for the purpose of receiving HIP 
signaling (especially I1) packets. This can be a local address, server 
reflexive address (i.e., the address NAT gives you), address of your HIP 
relay server, etc. And any of these may potentially have a non-standard 
UDP port.

You're right that *most* of the time just your relay's IP address is 
enough, but for example with a host without a HIP relay server but 
behind an endpoint independent NAT (as I explained before) this feature 
would be needed.

>> - ability for an application to set the port (in addition to IP 
>> address) for a peer locator when creating a HIT-locator mapping to the 
>> daemon
> 

I guess I don't need to repeat myself here :)

> (which are not currently in the scope of the draft).

I think TURN relaying is unrelated issue here -- unless you are using 
TURN to also relay I1 packets, but that's a bit more complicated because 
you would need to install TURN permissions at the TURN server for the 
Initiator.

>> In addition, it would be helpful to have a way to store the port 
>> number to DNS, but I don't see this as important as the two 
>> requirements above.
> 

OK. So I guess your preference would be a separate draft for this.

Cheers,
Ari

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 03 Jul 2009 01:05:10 +0900

Hi Thomas, all,

Excuse me for jumping in the discussion, but please find my comments 
inline.  I am co-authoring the multihome shim API draft.

> in shim6 is an IPv6 address, not a transport address.

well, I don't think this is a very big change for SHIM6 actually.
In theory, SHIM6 can support IPv4 locator as well.  And such an
idea was brought up and discussed in the SHIM6 WG in the past.
For instance, Section 1.3 of draft-nordmark-shim6-esd-01.txt
discusses the issue of IPv4 locator.  In my understanding,
SHIM6 is very much dependent on IPv6 with regard to the
security mechanism to protect identity ownwership (i.e., CGA/HBA).
However, there is not much dependency on IPv6 with regard to
locators because validity check of claimed locator is done by
the return routability test.

Although Figure 1 in the multihome draft shows that the
multihome shim layer is a sub-layer inside the IP layer,
this does not necessarily mean that UDP encap interface cannot
be handled as a locator.  I think this is common to HIP as
well (HIP lays between transport layer and IP layer, from
an architectural p.o.v., if I understand it correctly,
but it supports handling UDP encap interface as a locator).

> aspects.  In either case, I think we (HIP WG) should decide what we want

As a co-author of the multihome shim API document, I am willing
to improve the draft to support NAT Traversal.  It is not only
useful for HIP but also for SHIM6 (in the future) as mentioned
above.  Does this sound reasonable?

With regard to the data structure for storing IPv4 address and
a pair of UDP port numbers, let me come up with proposal later.
I need to discuss with co-authors of the multihome shim API draft.

Regards,
Shinta

> 
>>
>> 4.5. Source HIT Selection by the System:
>>
>>                   | Public DSA      | 130        | 7     |
>>                   | Public RSA      | 140        | 8     |
>>                   | [RFC3484] rules | 50-100     | 7     |
>>
>> Are the labels for Public DSA and RFC 3484 rules 
>> intentionally the same?
>>
> 
> They shouldn't be the same, but more broadly, I think this section may
> need some more work.  According to RFC 3484, the precedence value is
> used for sorting destination addresses, and the label for selecting
> source addresses, but the text here implies that precedence is used for
> source address selection.  It is not clear how RFC3484 rules relate to
> HITs, or whether they are referring to possible use of IP addresses.  
> 
> Tom
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Miika Komu <[email-masked]>
Date: Thu, 02 Jul 2009 21:21:10 +0300

Ari Keranen wrote:

Hi,

>>>>> From: Ari Keranen [mailto:[email-masked]] Sent: 
>>>>> Tuesday, June 30, 2009 4:22 AM
>>>>> To: HIP
>>>>> Here are some comments on the HIP native API draft. Indented text 
>>>>> is copy-pasted from the draft.
>>>>>
>>>>> receiving incoming HIP messages. Also the application should be 
>>>>> able create a HIT-to-locator mapping that includes a (possibly 
>> Agree, but a problem is that the same API is used by two protocols. 
>> The SHIM API should be modular enough to accommodate both of them. At 
>> the minimum, the SHIM draft could define some reserved fields for 
>> ports to support further extensions.
> 
> Sounds reasonable.
> 
>> We could increase the flexibility in the SHIM API for future 
>> extensions but I am not yet convinced for the need for applications to 
>> control the UDP port numbers in HIP API for the following reasons:
>>

I'd think it's quite common that NATs don't let you choose the port 
number which is the reason is why we need the HIP relay.

If some other service is occupying the HIP port on the same machine, the 
other service is breaking the IANA allocation. Nothing much we can do 
for that.

Do you actually mean the case where there are e.g. two hosts behind a 
single NAT controlled by the user of the hosts? In such a case, the 
"power" user could avoid use of the relay by specifying a non-standard 
port. I believe this would be an adequate use case to suit people who 
are capable of configuring bypass ports to their NAT boxes. Perhaps 
future HIP NAT extensions or implementation could actually define some 
uPNP extensions to automatize port reservation to remove this burden 
from the user.

Still, the use case above is an optimization more prone to failure than 
using a HIP relay...

>> * The NAT draft doesn't really handle properly the case where a host 
>> has single HIT but uses multiple UDP ports.
> 

I tried to invent a use case for the port numbers. I was thinking a 
(client) library based implementation that shares the HIT but uses 
different port numbers to demultiplex the different users/applications. 
Then two users on a single client would connect to a single server. This 
is not covered in the draft and I don't think it should be.

>> * The current version of the HIP API is oriented towards DNS and not 
>> DHT (see related comment on the end of this email).
> 

We have two choices:

* Define place holders for port numbers in the SHIM draft and describe 
the usage in HIP API or
* have the whole thing in the SHIM draft (it's about locators after all 
and SHIM API is all about locator handling)

I am open for the option which ever makes most sense to people.

>>> somehow. The NAT traversal related requirements for the API include 
>>> at least:
>>> address) for a peer locator when creating a HIT-locator mapping to 
>>> the daemon
>>
>> exchange. I think the TURN relay should be set also at the system 
>> level and not at the application layer to avoid user access control 
>> issues (which are not currently in the scope of the draft).
> 

Ok.

>> extensions are not really in the scope of the API drafts apart from 
>> the resolver interface.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 02 Jul 2009 21:34:01 +0300

Hi,

another reason why we waited with this WGLC was that we wanted to have a 
better understanding of HIP-based overlays in order to understand 
whether or not we wanted to include overlay-related functionality in 
this API. Comments on this topic are welcome.

Cheers,

Gonzalo

Gonzalo Camarillo wrote:
> Folks,
> Some time ago, we decided to wait with this WGLC until the NAT traversal 
> draft was more mature. The WGLC on the NAT traversal draft ends on 
> Sunday. We chose to make both WGLCs overlap a bit just in case somebody 
> wants to review both drafts at the same time.
> 
> This WGLC will end on July 12th.
> 
> Cheers,
> 
> Gonzalo
> HIP co-chair
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 2 Jul 2009 22:20:09 -0700

>I need to discuss with co-authors of the multihome shim API draft.

Thanks, it sounds reasonable to extend this if shim6 WG is willing, but from your comments, I take it that you are just going to focus on IPv4 NAT traversal?  I was wondering whether IPv6 NAT traversal also should be supported in the API in case such devices (or firewalls that filter the HIP protocol) become prevalent.

Tom

---

From: Ari Keranen <[email-masked]>
Date: Fri, 03 Jul 2009 16:48:49 +0300

Miika Komu wrote:
>>>>>> The draft does not seem to take NAT traversal into account. For 
>>>>>> NAT traversal purposes an application that is not using a resolver 
>>>>>> should be able to get the local UDP port used by the HIP daemon 
>>>>>> for receiving incoming HIP messages. Also the application should 
>>>>>> be able create a HIT-to-locator mapping that includes a (possibly 
>>> extensions but I am not yet convinced for the need for applications 
>>> to control the UDP port numbers in HIP API for the following reasons:
>>>
>>> * We have decided earlier to exclude support for user specific HITs 
>>> in the draft which are basically required for library-based 
>>> implementations.
>>
>> example, you could sit behind a NAT that allows nicely anyone to 
>> contact you, but you can't choose your public port number. Or some 
>> other service might be running on the HIP port, and thus HIP daemon 
>> needs to use some other port than what IANA reserves for the purpose.
> 

But if you are behind a friendly NAT, you could survive even without a 
HIP relay.

> other service is breaking the IANA allocation. Nothing much we can do 

Except run our service in some other port; and that's exactly what I'm 
suggesting that we should support.

> single NAT controlled by the user of the hosts? In such a case, the 

No, just a regular case where a single user is behind a NAT, and is able 
to receive data from any host to the address given by the NAT, but is 
not able to choose the port number.

> Still, the use case above is an optimization more prone to failure than 

Sure, a HIP relay would be a better option, but you may not always have 
such option available.

>> How come? Anyway, I would consider using multiple UDP ports a bit 
>> corner case anyway.
> 

OK

> I am open for the option which ever makes most sense to people.

Both are fine for me too.

Cheers,
Ari

---

From: Miika Komu <[email-masked]>
Date: Fri, 03 Jul 2009 16:53:22 +0300

> aspects.  In either case, I think we (HIP WG) should decide what we want

the NAT traversal part isn't yet included in neither of the drafts.

> HITs, or whether they are referring to possible use of IP addresses.  

Unless there are objections, I would suggest to leave this for future 
work. I have commented this section out from the preversion:

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

IMHO, the source HIT selection is more related to routing than the API 
syntax. I think this could be handled separately along with overlay 
routing issues which haven't received any feedback yet from the WG.

Comments?

---

From: Miika Komu <[email-masked]>
Date: Fri, 03 Jul 2009 16:56:50 +0300

Ari Keranen wrote:

Hi,

> traversal purposes an application that is not using a resolver should be 
> HIT-to-locator mapping that includes a (possibly non-standard) UDP port 
> number for a peer. Probably this is more of an issue for the shim6 API 
> draft, though.
> 
> Also, I think it would be worthwhile to clarify in section 3.2 what 
> socket options exactly are used for setting new HIT-to-locator mappings 
> when no (DNS) resolver is used. Maybe add a reference to section 4.6.
> 
> 
> In section 4.1. Socket Family and Address Structure Extensions:
> 
>    The
>    HIP_HIT_ANY equals to HIP_HIT_ANY_PUB or HIP_HIT_ANY_TMP.
> 
> Do you mean here that
> HIP_HIT_ANY = HIP_HIT_ANY_PUB | HIP_HIT_ANY_TMP
> or that the implementation is free to set HIP_HIP_ANY to any one of the 
> two? I'd guess you mean the binary/logical or, but it wasn't clear while 
> reading this the first time.

It's '|'. I hope the text is now more clear.

> 4.2. Extensions to Resolver Data Structures:
> 
>    The simultaneous use of both HIP_PREFER_ORCHID and
>    HIP_PREFER_PASSIVE_* flags produces a single sockaddr_hip structure
>    containing a wildcard address that the application can use either for
>    incoming (node argument is NULL in getaddrinfo) or outgoing
>    communications (node argument is non-NULL).
> 
> I think you should introduce the HIP_PREFER_PASSIVE_* flags before this. 
> Actually, I couldn't find any explanation of their semantics in the 
> whole document.

Done.

> 4.6. Explicit Handling of Locators:
> 
>    An application that initiates a connection using a connection
>    oriented socket to a particular host at a known address or set of
>    addresses can invoke SHIM_LOCLIST_PEER socket option.
> 
> What about UDP (non-connection oriented) sockets? I hope you can also 
> use the LOCLIST option with them.

Added a paragraph on datagram-oriented applications.

> Are the labels for Public DSA and RFC 3484 rules intentionally the same?

No, my bad. I have commented this section for the time being unless 
people really want it there. It requires more work.

> Editorial nits/comments:
> 
> The table of contents is partially double-spaced but all the other HIP 
> RFCs have fully single-spaced TOCs, so it would make sense to use only 
> single spacing here too.
> 
> 
> 4.1. Socket Family and Address Structure Extensions:
> 
>    The port number ship_port is two
>    octets in network byte order. and the ship_hit is 16 octets in
> 
> A period in the middle of a sentence.
> 
> 
> 4.4. Validating HITs:
> 
>          short sockaddr_is_srcaddr(struct sockaddr *srcaddr
>                                    uint64_t flags);
> 
> Missing comma between the arguments.
> 
> 
> 4.6. Explicit Handling of Locators:
> 
> The description for SHIM_LOC_LOCAL_SEND and SHIM_LOC_PEER_SEND in Figure 
> 6 implies that the options have only "set" semantics while they seem to 
> also work with "get". Also, I'd call that a "table" instead of "figure".
> 
> 
>    [...] uses the first address (if multiple are provided, or else the
>    application can override this by setting SHIM_LOC_PEER_PREF to one of
>    the addresses in SHIM_LOCLIST_PEER.
> 
> Missing closing parenthesis.

Fixed. New version is here:

Thanks for your comments!

---

From: Miika Komu <[email-masked]>
Date: Fri, 03 Jul 2009 17:00:45 +0300

Ahrenholz, Jeffrey M wrote:

Hi,

> Here are additional comments on the native API draft, mostly editorial
> nits.
> 
> You might reference ORCHIDs earlier on (maybe second or third paragraph
> of introduction) as the first time they appear in this draft is section
> 4.2.

Done.

> Should the resolver function be dealing with sockaddr_orchid
> instead of sockaddr_hip? The naming is a little strange to have the
> HIP_PREFER_ORCHID flag return sockaddr_hip. (See also a note below about
> typedef orchid_t ...)

I agree that the HIT vs. ORCHID usage was confusing. I replaced all 
orchid names with HITs in order to unify the naming scheme in the API. 
Is it ok now?

> Abstract, Page 2
> current sockets API for the Host Identity Protocol
>                         ^^^
> Section 1., Page 4
> are of an experimental nature  *or* are experimental in nature
>        ^^                             ^^(deleted of) ^^
> Section 3.1 Page 5
> (parenthesis might make these steps more clear in the text)
> calls the resolver in step (a) to resolve an FQDN in step (b).
>                            ^ ^                    ^^      ^ ^
> and a set of locators in step (c).
>                       ^^      ^ ^
> Section 3.1 Page 5
> caches the HIT to locator mapping with the HIP module
>                                   ^^^^
> Figure 1 Page 5
> I'm not sure you need the double text <HITS+locators = HITs+locs>
> Maybe just <HITs+locs> or <HITs+locs.> would suffice?
> 
> Section 3.2 Page 5-6
> suggest replacing:
>   The resolver associates implicitly the HIT with the locator(s)
>   by e.g. communicating the HIT-to-IP mapping to the HIP daemon. 
> with this:
>   The resolver may implicitly associate the HIT with its 
>   locator(s) by communicating the HIT-to-IP mapping to the
>   HIP daemon.

Done.

> Page 3 says:
> "This document specifies extensions to [RFC3493] to define a new
>  socket address family, AF_HIP.  The macro AF_HIP is used as an alias
>  for PF_HIP in this document because the distinction between AF and PF
>  has been lost in practice."
> but then Section 4.1 Page 6, 2nd paragraph talks about using PF_HIP
> "The use of the PF_HIP constant" ...

I rephrased this, please check if it is ok now.

> In Figure 2 on Page 6, there is typedef struct in6_addr hip_hit_t. It
> may be worthwhile to reference the RFC 4843 ORCHIDs so that the HIT is
> defined as an ORCHID such as: typedef struct in6_addr orchid_t; typedef
> orchid_t hip_hit_t;

I am not sure what to do about it because I decided to unify the 
constants just to use always "hit".

> Section 4.1 Page 7
> identifiers refer to the use of anonymous identifiers
>                              ^^
> Section 4.1 Page 8
> it should be noted that different
>              ^^^^^ (replaced noticed)
> Section 4.2 Page 8
> to be used by applications to query
>                          ^
> The application must set both the
> ^^^
> The application denotes its preference
> ^^^
> Section 4.2 Page 10
> cache the locator mappings with the HIP module
>                            ^^^^
> it should be noted that the application
>              ^^^^^
> Section 4.5 Page 11
> When an application using a AF_HIP-based
>      ^^
> Section 4.5 Page 12
> When the system provides multiple keys of the same type
>      ^^^                                  ^^^
> Section 4.5 Page 12
> calls and in the ancillary data of datagram packets
>                  ^^^^^^^^^
> Section 9 Page 15
> Jan Melen appears to have provided twice the feedback :)

Fixed. Thanks!

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 6 Jul 2009 07:50:50 -0700

> > of introduction) as the first time they appear in this 

OK, in the new ORCHID text, you might use "derived" instead of
"derivated".

> orchid names with HITs in order to unify the naming scheme in 

yes, I think it is clearer now

> I rephrased this, please check if it is ok now.

looks good

> > typedef struct in6_addr orchid_t; typedef orchid_t hip_hit_t;
> 

yes now all the constants use "hit" so the "orchid" name is not needed

-Jeff

---

From: Miika Komu <[email-masked]>
Date: Mon, 06 Jul 2009 19:08:00 +0300

Hi,

> OK, in the new ORCHID text, you might use "derived" instead of

thanks. This will appear in the next version.

> yes now all the constants use "hit" so the "orchid" name is not needed

Ok, thanks.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 8 Jul 2009 11:58:24 -0700

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

Miika, I reviewed this preview version and have some more comments.

1) I think that Figure 3.1 and the related prose description could be
clearer by referring specifically to the records that are being
retreived from DNS.  In particular:

- step a) could say explicitly that a HIP RR is being fetched, step b)
in the diagram could say "QNAME=FQDN, QTYPE=HIP" instead of <FQDN>, step
c in the diagram should say "HIP RR(s)" instead of "<HITs+locs>".  Or
else, if you intend to abstract this and you mean to say that "b)
<FQDN>" refers to both possible fetching of HIP RRs and A/AAAA records,
and that steps b and c may in fact be several transactions, the
corresponding text should clarify this.  

- step e) should be generalized to show that not only HITs but also
sockaddr_in or sockaddr_in6 are passed back to the application

- step f) should probably not just say "f. connect(<HIT>)" but should
show or describe that there are several possible socket messages using
the new address family and the new HIP addresses fetched in step e,
including socket(), setsockopt(), sendmsg(), bind(), connect(), ...

2) section 4.2 on the use and extension of getaddrinfo seems unclear to
me on a few points

- why is AI_EXTFLAGS necessary to be set if the caller does not care
about changing the source HIT selection preferences?  why can't you just
set ai_protocol to IPPROTO_HIP?

- I think that in general, it would be clearer to talk about source
address selection separately, and not introduce all of these flags
referring to source address selection in this section, because they also
apply to sockets and not just getaddrinfo

- it is not clear what the behavior should be if the resolver cannot
determine whether HITs are public or anonymous 

- in the second paragraph on page 9, it implies that DNS, by default,
will spoof the resolution and return HITs and LSIs in
sockaddr_in6/sockaddr_in structures.  (by the way, the reference should
be to RFC5338).  I would make this change to imply that this is not the
recommended default behavior:
s/In such a case, the DNS agent returns transparently.../In such a case,
the DNS agent may, according to local policy, return transparently.../
and later:
s/To disable this behavior/To override this local policy/

- in general, my understanding is that the setting of PREFER_SRC...
flags does not cause the glibc to filter addresses and only return those
that match, but instead influences the order in which the possibly
multiple destination addresses are returned to the caller.  In any case,
I am not sure that PREFER_SRC_TMP and PREFER_SRC_PUBLIC make much sense
here because the destination HITs are all going to be public and these
flags will not affect HIT ordering.  

- Is it really true that HIP_PREFER_PASSIVE_* produces a single
sockaddr_hip structure containing a wildcard and not an explicit HIT?
If so, what is the point of this call-- the application can populate the
appropriate wildcard itself?

3) section 4.4 on the validation function

- do you really need 64-bits of flag?
- the flag names in Table 2 should probably be changed to
HIP_PREFER_HIT_TMP and HIP_PREFER_HIT_PUBLIC
- again, it should be clarified what the behavior is if the system can
tell whether the identifier is a HIT but can't tell whether it is a TMP
or PUBLIC

Regards,
Tom

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 09 Jul 2009 18:53:49 +0900

Hi Thomas,

Thank you for your comments and sorry for my delayed response.
Please find my comment below.

> Thanks, it sounds reasonable to extend this if shim6 WG is willing, but from your comments, I take it that you are just going to focus on IPv4 NAT traversal?  I was wondering whether IPv6 NAT trave…

Thank you.

Let us define the locator management API taking NAT into consideration. 
  Answering to your question, yes, we (at least I) have been thinking 
only IPv4 NAT.  But I see your point that NAT is not necessarily IPv4 
but there could be IPv6 NAT as well.  Then, let us also take this into 
account.

Now we are updating the multihome API document with NAT support.  Will 
send it to the HIP list when it's ready (hopefully before the cutoff).

Regards,
Shinta

---

From: Miika Komu <[email-masked]>
Date: Fri, 10 Jul 2009 12:49:47 +0300

Hi,

a new version is available from here:

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

It is based on comments from you and the minor comment from Jeff is
included. I didn't have time to proof read all the changes yet, so I 
might apply small nits here and there.

Cut-off deadline is on Monday. I assume that I have follow the official 
schedule and I'll submit the final 07 version on Monday. Please comment 
before that if you can.

> including socket(), setsockopt(), sendmsg(), bind(), connect(), ...

Done, please suggest further clarifications if necessary. I think we
should keep this description simple to give an overview of how the API
works.

> set ai_protocol to IPPROTO_HIP?

Or AF_HIP, like I have put in the current text. I am not sure what to do
with IPPROTO_HIP.

Your were right about AI_EXTFLAGS, it was unnecessarily coupled with the
basic HIP resolution.

> apply to sockets and not just getaddrinfo

Moved to section 4.4.

> determine whether HITs are public or anonymous 

Added:

"Similarly to [RFC5014], the sockaddr_is_srcaddr() function returns 1
when the address satisfies the given flags and 0 otherwise.  Value -1
denotes a failure."

> s/To disable this behavior/To override this local policy/

Fixed.

> flags will not affect HIT ordering.  

You're right, the semantics were ambiguous. After some thinking, I 
thought the following would be more clear:

    The same flags can also be used with getaddrinfo() when the
    application asks the resolver to assign a local wildcard HIT to be
    used with the bind() socket call.  In such a case, the node argument
    for getaddrinfo() must be NULL and input flags must include the
    AI_PASSIVE flag.  When the AI_EXTFLAGS is unset, the resolver returns
    a sockaddr_hip structure with ship_hit field prefilled with the
    HIP_HIT_ANY macro that was described in Section 4.  When AI_EXTFLAGS
    is set, the resolver prefills the returned sockaddr_hip structure for
    the conveniency of the application as listed in Table 2.

Does that work for you?

> appropriate wildcard itself?

As indicated by the last quoted text, it is just for the conveniency of 
the application. The existing getaddrinfo() interface provides such 
functionality for filling wildcard or loopback addresses for bind(). I 
have no idea how common it is for applications to use it in practice, 
but I believe we should define the same conveniency interface.

Btw, I simplified the jungle of HIP_PREFER_PASSIVE_* flags without 
reducing any functionality. Now there are just two flags instead of the 
original seven.

> - do you really need 64-bits of flag?

The function provide a superset of inet6_is_srcaddr() which could have 
been defined originally in a little bit more flexible way:

    The function has also 64 bit flags
    instead of 32 bits.  This new function handles the same flags as
    defined in [RFC5014] in addition to some two HIP-specific flags for
    anonymous and public HITs, HIP_PREFER_SRC_HIT_TMP and
    HIP_PREFER_SRC_HIT_PUBLIC.

64 bits should guarantee that we don't run out of bits for some while 
due to the shared interface. Do you agree with this?

> HIP_PREFER_HIT_TMP and HIP_PREFER_HIT_PUBLIC

The flags are now "HIP_PREFER_SRC_HIT_xx" since destination HIT is 
supposed to be public by definition. Is this ok?

> tell whether the identifier is a HIT but can't tell whether it is a TMP

I added:

    Similarly to [RFC5014], the sockaddr_is_srcaddr() function returns 1
    when the address satisfies the given flags and 0 otherwise.  Value -1
    denotes a failure.

---

From: Miika Komu <[email-masked]>
Date: Fri, 10 Jul 2009 14:32:13 +0300

Miika Komu wrote:

Hi,

> reducing any functionality. Now there are just two flags instead of the 

if you agree on the conveniency flags for getaddrinfo(), should we 
define them also for outbound opportunistic connections?

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 10 Jul 2009 20:56:15 +0900

Hi all,
(please allow me to change the subject of the thread)

As I mentioned, we (authors of mutlhome shim API draft) are updating the 
multihome shim API draft taking NAT Traversal support into account. 
Below is what we have now in the draft.  Basically, we modified the data 
structure for storing locator information so that it can contain UDP 
encapsulation as well.  Also, a locator behind NAT could be either IPv4 
or IPv6 (taking Thomas's comment into account).  Any 
comments/suggestions are welcome.  Please note that we are planning to 
submit the updated draft (-09) before the cutoff.  Thank you.

---(beginning of quote)---
7.1.  Placeholder for Locator Information

    As defined in Section 5, the SHIM_LOC_LOCAL_PREF, SHIM_LOC_PEER_PREF,
    SHIM_LOCLIST_LOCAL, and SHIM_LOCLIST_PEER socket options need to
    handle one or more locator information.  Locator information includes
    not only the locator itself but also additional information about the
    locator which is useful for locator management.  A new data structure
    is defined to serve as a placeholder for the locator information.

    Figure 4 illustrates the data structure called shim_locator which
    stores a locator information.

         struct shim_locator {
                 uint8_t    lc_family;       /* address family */
                 uint8_t    lc_proto;        /* protocol */
                 uint16_t   lc_port;         /* port number */
                 uint16_t   lc_flags;        /* flags */
                 uint16_t   lc_pref;         /* preference value */
                 uint32_t   lc_ifidx;        /* interface index */
                 struct in6_addr lc_addr;    /* address */
         };

                      Figure 4: shim locator structure

    lc_family
       Address family of the locator (e.g.  AF_INET, AF_INET6).  It is
       required that the parameter contains non-zero value indicating the
       exact address family of the locator.
    lc_proto
       Internet Protocol number for the protocol which is used to handle
       locator behanid NAT.  Typically, this value is set as UDP (17)
       when the locator is a UDP encapsulation interface.

Komu, et al.            Expires November 8, 2009               [Page 28]

Internet-Draft            Multihoming Shim API                  May 2009

    lc_port
       Port number which is used for handling locator behind NAT.
    lc_flags
       Each bit of the flags represents a specific characteristics of the
       locator.  Hash Based Address (HBA) is defined as 0x01.
       Cryptographically Generated Address (CGA) is defined as 0x02.
    lc_pref
       Preference of the locator.  The preference is represented by an
       integer.
    lc_ifidx
       Interface index of the network interface to which the locator is
       assigned.  This field should be valid only in a read
       (getsockopt()) operation.
    lc_addr
       Contains the locator.  In the case where a locator whose size is
       smaller than 16 bytes, an encoding rule should be provided for
       each locator of a given address family.  For instance, in case of
       AF_INET (IPv4), the locator should be in the format of an IPv4-
       mapped IPv6 address as defined in RFC 4291[RFC4291].

7.1.1.  Handling Locator behind NAT

    Note that the locator information MAY contain a locator behind a
    Network Addresss Translator (NAT).  Such a situation may arise when
    the host is behind the NAT and uses a local address as a source
    locator to communicate with the peer.  Note that a NAT traversal
    mechansim for HIP is defined, which allows HIP host to tunnel control
    and data traffic over UDP[I-D.ietf-hip-nat-traversal].  Note also
    that the locator behind NAT is not necessarily an IPv4 address but it
    can be an IPv6 address.  Below is an example where the application
    sets a UDP encapsulation interface as a source locator when sending
    IP packets.

Komu, et al.            Expires November 8, 2009               [Page 29]

Internet-Draft            Multihoming Shim API                  May 2009

        struct shim_locator locator;
        struct in6_addr ia6;

        /* copy the private IPv4 address to the ia6 as an IPv4-mapped
           IPv6 address */

        memset(&locator, 0, sizeof(locator));

        /* fill shim_locator data structure */
        locator.lc_family = AF_INET;
        locator.lc_proto = IPPROTO_UDP;
        locator.lc_port = 50500;
        locator.lc_flags = 0;
        locator.lc_pref = 0;
        locator.lc_ifidx = 3;

        memcpy(&locator.lc_addr, &ia6, sizeof(ia6));

        setsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator,
                   sizeof(locator));
---(end of quote)---

Regards,
Shinta

Shinta Sugimoto wrote:
>> Thanks, it sounds reasonable to extend this if shim6 WG is willing, 
>> but from your comments, I take it that you are just going to focus on 
>> IPv4 NAT traversal?  I was wondering whether IPv6 NAT traversal also 
>> should be supported in the API in case such devices (or firewalls that 
>> filter the HIP protocol) become prevalent.
> 
> Thank you.
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 10 Jul 2009 15:58:59 -0700

>     can be an IPv6 address. 

And due to a 6/4 translator, the address family of the tunnel
endpoints could be different, too.

-d

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sat, 11 Jul 2009 21:15:19 -0700

> From: Miika Komu [mailto:[email-masked]] 
> Sent: Friday, July 10, 2009 2:50 AM
> To: Henderson, Thomas R
> Cc: HIP

I think that if we just try to limit the diagram to HIP information, it
would be simple.  As it reads right now, I might suggest in step b)
delete "QTYPE=HIP" since, in the figure, steps b) and c) are
asymmetrical (b only asks for HIP, and c responds with A/AAAA).  I think
that the text describes that there may be other queries for A/AAAA
records involved.

> when the address satisfies the given flags and 0 otherwise.  Value -1

I had a hard time understanding the distinction between 0 and -1 when I
read RFC5014, and here, I think what is unclear is whether the library
necessarily knows whether a HIT is public or not, and whether it should
return 0 or -1.  I think it would be clearer to maybe add "we assume
that the system will be able to resolve each HIT as either a public or
anonymous HIT on the basis of local metadata, or other policy decision."

Perhaps value 1 should equal "is my HIT and satisfies flags", value 0
"is my HIT but does not satisfy flags", and value -1 "is not a HIT, or
is not one of my HITs"

OK

OK

> due to the shared interface. Do you agree with this?

I'm OK with it.

OK 
>     when the address satisfies the given flags and 0 

same comment as above-- I don't think it hurts to be explicit and list
these out what these mean rather than just refer to RFC5014 reference.

Regards,
Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 12 Jul 2009 14:59:12 -0700

> Sent: Friday, July 10, 2009 4:32 AM
> To: Henderson, Thomas R
> Cc: HIP

I think the current flags:
- HIP_PREFER_SRC_HIT_TMP
- HIP_PREFER_SRC_HIT_PUBLIC 
may be useful for two reasons.

1) alignment with how getaddrinfo() AI_PASSIVE works in the non-HIP
case.  Yes, the app could fill in these macros directly, but this is
true of the non-HIP case as well (app could fill in INADDR_ANY).  So, it
is probably best to just align with how IPv6 works.

2) pass in something like an IPV6_ADDR_PREFERENCES to a socket, as in
section 6 of RFC5014.  However, I don't see that option in the current
draft-- there is no SHIM_*** optname that relates to the setting of
preferences on the EID that is selected, nor do I see it in the current
shim6 document.  As you mention, this would help for opportunistic
connections, but I think also for other connections as well.

One possibility is to insert this section after table 2; any comments on
this?

4.5  Additions to the Socket Interface

   The Socket API for Source Address Selection [RFC5014] defines socket
options 
   to allow applications to influence source address selection
mechanisms.  In some cases,
   HIP-aware applications may want to influence source HIT selection; in
particular, whether
   an outbound connection should use a published or anonymous HIT.
Similar to 
   IPV6_ADDR_PREFERENCES defined in RFC 5014, the following socket
option
   HIT_PREFERENCES is defined for IPPROTO_HIP-based sockets.  This
socket option can be used with
   setsockopt() and getsockopt() calls to set and get the HIT
   selection preferences affecting a HIP-enabled socket.
   The socket option value (optval) is a 32-bit unsigned integer
   argument.  The argument consists of a number of flags where each flag
   indicates an address selection preference that modifies one of the
   rules in the default HIT selection; these flags have been introduced
above in Table 2.

   HIP_PREFER_SRC_HIT_TMP /* Prefer an anonymous HIT */
   HIP_PREFER_SRC_HIT_PUBLIC /* Prefer a public HIT */

   If the system is unable to assign the type of HIT that is requested,
at HIT selection
   time, the socket call (connect (), sendto(), or sendmsg()) will fail
and errno will be
   set to EINVAL.  If the application tries to set both of the above
flags for the same socket,
   this also results in the error EINVAL.

---

From: Ari Keranen <[email-masked]>
Date: Mon, 13 Jul 2009 13:43:45 +0300

Hi Shinta,

That change should be good enough at least for the NAT traversal 
scenarios I had in mind. Thanks!

Although I guess that if lc_proto != 0, it means that one uses transport 
layer encapsulation with port lc_port and protocol lc_proto? This could 
be stated more explicitly in the draft. Maybe something like

    lc_proto
       Internet Protocol number of a transport layer protocol if 
transport layer encapsulation is used with the locator. Set to 
IPPROTO_UDP (17) for UDP or zero if no transport layer encapsulation is 
used.

    lc_port
       The transport layer port number, or zero if lc_proto is zero.

Also I'm not sure if I fully understood the second sentence of 7.1.1:

    Note that the locator information MAY contain a locator behind a
    Network Addresss Translator (NAT).  Such a situation may arise when
    the host is behind the NAT and uses a local address as a source
    locator to communicate with the peer.

Shouldn't the "local address" be rather the address NAT gives to the 
host (i.e., server or peer reflexive address) since that's the one host 
uses, from the peer's point of view, as the source locator? Or did you 
mean to say that this situation arises if the host uses *the* local 
address that is behind the NAT (and may have some other local address 
that is not)?

also: s/Addresss/Address/

And perhaps change the title of the section to something like "Handling 
Locator with Transport Layer Encapsulation", since this isn't really a 
fully working NAT traversal solution, and might be also usable for other 
than NAT traversal purposes.

Cheers,
Ari

Shinta Sugimoto wrote:
>>> should be supported in the API in case such devices (or firewalls 
>>> that filter the HIP protocol) become prevalent.
>>
>> Thank you.
>>
>> Let us define the locator management API taking NAT into 
>> consideration.  Answering to your question, yes, we (at least I) have 
>> been thinking only IPv4 NAT.  But I see your point that NAT is not 
>> necessarily IPv4 but there could be IPv6 NAT as well.  Then, let us 
>> also take this into account.
>>

---

From: Miika Komu <[email-masked]>
Date: Mon, 13 Jul 2009 15:03:16 +0300

Hi,

I have applied the comments in this email to third iteration:

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

Done.

> "is my HIT but does not satisfy flags", and value -1 "is not a HIT, or

It says now:

    When given an AF_INET6 socket, sockaddr_is_srcaddr() behaves as
    inet6_is_srcaddr() function as described in [RFC5014].  With AF_HIP
    socket, the function returns 1 when the HIT contained in the socket
    address structure corresponds to a valid HIT of the local host and
    the HIT satisfies the given flags.  The function returns -1 when the
    HIT does not belong to the local host or the flags are not valid
    The function returns 0 when the preference flags are valid but the
    HIT does not match the given flags.

Is this ok?

Ok.

---

From: Miika Komu <[email-masked]>
Date: Mon, 13 Jul 2009 16:48:41 +0300

Hi,

a new preversion with your comments is here:

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

> is probably best to just align with how IPv6 works.

There seems to be some problems with the flags:

1. They are coupled with socket options (which are not flags) of your 
description
2. In my opinion, the description brings too little convenciency when 
compared to the added complexity.

I would like to resolve these problems by removing the HIP_PREFER flags 
from the context of the getaddrinfo. Also, I would state that AI_PASSIVE 
flag will be ignored with AF_HIP and NULL hints gives a list of all 
local HITs. Does this work for you?

To make the decision easier, here's a recap how the resolver works 
(without HIP) in relation to the passive flag:

hints=NULL and AI_PASSIVE=true:

   The returned socket addresses will  be  suitable  for  bind(2)ing  a
   socket  that  will  accept(2)  connections.   The  returned  socket
   address  will  contain the "wildcard address" (INADDR_ANY for IPv4
   addresses, IN6ADDR_ANY_INIT for IPv6 address).  The wildcard address
   is used by applications (typically servers) that intend to accept
   connections on any  of the hosts network addresses.

hints=!NULL and AI_PASSIVE=true:

    The AI_PASSIVE flag is ignored.

hints=NULL and AI_PASSIVE=false:

    The network address will be set  to  the  loopback  interface
    address  (INADDR_LOOPBACK  for  IPv4  addresses,
    IN6ADDR_LOOPBACK_INIT for IPv6 address); this is used by
    applications that intend to communicate with peers running
    on the same host.

hints=!NULL and AI_PASSIVE=false:

   Returned socket addresses will be suitable for use with connect(2),
   sendto(2), or sendmsg(2).

My suggestion should retain compatibility with the existing semantics 
and make the API more simple.

>    this also results in the error EINVAL.

I added this section. However, I thought that it would be better to 
order the sections as follows:

4.4.  Selection of Source HIT Type
4.5.  Verification of Source HIT Type

Is this ok?

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 13 Jul 2009 09:04:40 -0700

> Sent: Monday, July 13, 2009 6:49 AM
> To: Henderson, Thomas R
> Cc: HIP

Yes, I have no problem with that.

> hints=NULL and AI_PASSIVE=true:

I think you mean nodename==NULL, since AI_PASSIVE or any flag cannot be
true with a null hints.  But otherwise, yes, I agree (your second and
fourth cases below are really the same case, since AI_PASSIVE is
ignored).

> and make the API more simple.

Agree.

> 4.5.  Verification of Source HIT Type

Yes.  Here is one more getaddrinfo-related suggestion that I have for
now:

Section 4.2:

OLD TEXT:

   An application resolving with the ai_family field set to zero in the
   input argument may receive any kind of socket address structures,
   including sockaddr_hip.  The same occurs when the input argument is
   NULL.  When the application should resolve only HITs contained in
   sockaddr_hip structures, it should set the ai_family field to AF_HIP.

NEW TEXT:

   An application resolving with the ai_family field set to AF_UNSPEC in
the
   input argument may receive any kind of socket address structures,
   including sockaddr_hip.  When the application wants to receive only
HITs contained in
   sockaddr_hip structures, it should set the ai_family field to AF_HIP.

---

From: Miika Komu <[email-masked]>
Date: Mon, 13 Jul 2009 21:41:38 +0300

Hi,

new preversion is here based on your comments:

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

> Yes, I have no problem with that.

Applied:

The resolver ignores the AI_PASSIVE flag when the application sets the 
family in hints to AF_HIP.

> fourth cases below are really the same case, since AI_PASSIVE is

Yes.

>    sockaddr_hip structures, it should set the ai_family field to AF_HIP.

Applied.

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 14 Jul 2009 19:17:38 +0900

Hi Ari,

Thanks for your comments.  Please find my comments below.

Ok, thanks.

> IPPROTO_UDP (17) for UDP or zero if no transport layer encapsulation is 

I see, and agree that the text you suggested would be more user-friendly.
We should probably use 255 (instead of zero) to explicitly mean that the 
locator is NOT an transport layer tunneling as I noticed that IP 
protocol number 0 is reserved for IPv6 hop-by-hop option.

So, let us update the text as follows:

    lc_proto
       Internet Protocol number of a transport layer protocol if
transport layer encapsulation is used with the locator. Set to
IPPROTO_UDP (17) for UDP or 255 if no transport layer encapsulation is
used.

>       The transport layer port number, or zero if lc_proto is zero.

agree.

lc_port
	The transport layer port number, or zero if lc_proto is 255.

> address that is behind the NAT (and may have some other local address 

I see that the text is a bit confusing.
I meant a situation where a host is behind the NAT, gets a private 
address (e.g., 10.0.0.4) assigned by the local DHCP server which is 
usually running on top of the NAT device, and the application running on 
top of the host wants to use a transport layer tunneling interface as 
the source locator.  What about the following?

Note that the locator information MAY contain a locator which represents 
a transport layer tunnel.  Such a situation may arise when the host is 
behind the NAT and gets an private IP address assigned by the NAT, and 
the host establishes a transport layer tunnel with the peer to traverse NAT.

> also: s/Addresss/Address/

thanks. this has been corrected when we submitted 09 version.

> than NAT traversal purposes.

Ok, I see.  Will change the title in the next revision.

thanks again for your comments!

Regards,
Shinta

>> As I mentioned, we (authors of mutlhome shim API draft) are updating 
>> the multihome shim API draft taking NAT Traversal support into 
>> account. Below is what we have now in the draft.  Basically, we 
>> modified the data structure for storing locator information so that it 
>> can contain UDP encapsulation as well.  Also, a locator behind NAT 
>> could be either IPv4 or IPv6 (taking Thomas's comment into account).  
>> Any comments/suggestions are welcome.  Please note that we are 
>> planning to submit the updated draft (-09) before the cutoff.  Thank you.
>>
>>>> but from your comments, I take it that you are just going to focus 
>>>> on IPv4 NAT traversal?  I was wondering whether IPv6 NAT traversal 
>>>> also should be supported in the API in case such devices (or 
>>>> firewalls that filter the HIP protocol) become prevalent.
>>>
>>> Thank you.
>>>
>>> Now we are updating the multihome API document with NAT support.  
>>> Will send it to the HIP list when it's ready (hopefully before the 
>>> cutoff).
>>>
>>> Regards,
>>> Shinta

---

From: Ari Keranen <[email-masked]>
Date: Wed, 15 Jul 2009 08:48:51 +0300

Hi Shinta,

Comments inline.

Shinta Sugimoto wrote:
> Ari Keranen wrote:
>> Although I guess that if lc_proto != 0, it means that one uses 
>> transport layer encapsulation with port lc_port and protocol lc_proto? 
>> This could be stated more explicitly in the draft. Maybe something like
>>
>>    lc_proto
>> IPPROTO_UDP (17) for UDP or zero if no transport layer encapsulation 
>> is used.
> 

Good point, 255 as a reserved value is better for this.

>     The transport layer port number, or zero if lc_proto is 255.

These are good.

>> host (i.e., server or peer reflexive address) since that's the one 
>> host uses, from the peer's point of view, as the source locator? Or 
>> did you mean to say that this situation arises if the host uses *the* 
>> local address that is behind the NAT (and may have some other local 
>> address that is not)?
> 

OK, this is much better. Just a couple of editorial nits:
s/behind the NAT/behind a NAT/
s/an private IP/a private IP/
s/traverse NAT/traverse NATs/

>> And perhaps change the title of the section to something like 
>> "Handling Locator with Transport Layer Encapsulation", since this 
>> isn't really a fully working NAT traversal solution, and might be also 
>> usable for other than NAT traversal purposes.
> 

You're welcome.

Cheers,
Ari

>>> modified the data structure for storing locator information so that 
>>> it can contain UDP encapsulation as well.  Also, a locator behind NAT 
>>>> consideration.  Answering to your question, yes, we (at least I) 
>>>> have been thinking only IPv4 NAT.  But I see your point that NAT is 
>>>> not necessarily IPv4 but there could be IPv6 NAT as well.  Then, let 
>>>> us also take this into account.
>>>>

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 17 Jul 2009 13:44:37 +0900

Hi Ari,

Sorry for the delayed response.
I agree with your suggestions and will incorporate them in the next 
revision.  Thanks!

Regards,
Shinta

Ari Keranen wrote:
>>> transport layer encapsulation with port lc_port and protocol 
>>> lc_proto? This could be stated more explicitly in the draft. Maybe 
>>> something like
>>>
>>>    lc_proto
>> We should probably use 255 (instead of zero) to explicitly mean that 
>> the locator is NOT an transport layer tunneling as I noticed that IP 
>> usually running on top of the NAT device, and the application running 
>> on top of the host wants to use a transport layer tunneling interface 
>> as the source locator.  What about the following?
>>
>> Note that the locator information MAY contain a locator which 
>> represents a transport layer tunnel.  Such a situation may arise when 
>> the host is behind the NAT and gets an private IP address assigned by 
>> the NAT, and the host establishes a transport layer tunnel with the 
>> peer to traverse NAT.
> 
>>> isn't really a fully working NAT traversal solution, and might be 
>>> also usable for other than NAT traversal purposes.
>>
>>>> it can contain UDP encapsulation as well.  Also, a locator behind 
>>>> NAT could be either IPv4 or IPv6 (taking Thomas's comment into 
>>>> account).  Any comments/suggestions are welcome.  Please note that 
>>>> we are planning to submit the updated draft (-09) before the 
>>>> cutoff.  Thank you.
>>>>
>>>>>> Thanks, it sounds reasonable to extend this if shim6 WG is 
>>>>>> willing, but from your comments, I take it that you are just going 
>>>>>> to focus on IPv4 NAT traversal?  I was wondering whether IPv6 NAT 
>>>>>> traversal also should be supported in the API in case such devices 
>>>>>> (or firewalls that filter the HIP protocol) become prevalent.
>>>>>
>>>>> Thank you.
>>>>>
>>>>> not necessarily IPv4 but there could be IPv6 NAT as well.  Then, 
>>>>> let us also take this into account.
>>>>>