hipl-core team mailing list archive

[Miika Komu <miika@xxxxxx>]

On 08/25/2010 06:16 PM, Tobias Heer wrote:

Hi,

(btw, I think the topic of this comment not for the right bug report but
answering nevertheless)

> I think reducing the failure probability during BEX is a really good
> thing but I also think that we should have some specification and
> documentation in the form of a draft to back up the experimentation.
> I also think shotgun goes into an interesting direction but I think
> there is some more research and coding necessary before it evolves
> into a feature with long-term support.
>
> I did express my interest and doubts about shotgun on the hipsec
> list before. You may want to read the conversation for more
> reasoning.
>
> http://www.ietf.org/mail-archive/web/hipsec/current/msg02837.html
> http://www.ietf.org/mail-archive/web/hipsec/current/msg02839.html

I thought I already answered your concerns :)

http://www.ietf.org/mail-archive/web/hipsec/current/msg02844.html

If you want to avoid expensive GPRS links, we need a policy manager. Or
plain simple, turn the extension off, like it is now as default.

> I am not sure if I should lean towards keeping or abandoning it,
> though. I guess my recommendation strongly depends on whether it is
> still actively developed and maintained or if it is "just there". If
> it is maintained and will serve as input for the IETF or IRTF I think
> it should definitely stay (but possibly in a feature branch until
> the experimentation is completed). If it is not maintained anymore
> not, we will have some optimization without proper documentation (in
> the form of specification and research papers) that is only supported
> by HIPL and it will decay because of lacking support.
>
> Some general questions that may make the decision to keep or discard
> it easier:
> * Is the concept well understood? Are its side effects
> (e.g., interactions with middleboxes) understood and documented?

I believe the concept is well understood. I don't have any bad
experiences with non-HIP middleboxes. Since the amount of HIP-aware
middleboxes is practically non-existent, we can only speculate about it.

It should be noticed that the extension is designed so that it affects
the end-host implementing it (and not its peer). So it's a local
optimization.

> * Is it well tested? Do we know exactly when it works and when it
> doesn't?

I have been using it but stopped because Baris has not completed
mobility support yet.

> * Does shotgun solve an real problem that people notice?

I have problems with Teredo connectivity at the office. The current
address selection is dumb and ends up usually picking up the non-working
Teredo address for me. So it solved the problem for me.

> * Does it solve the problem well?

The ICE-based NAT traversal approach offers something similar but is
utterly complicated and not supported by the code base anymore. The
native NAT traversal approach is far better, but even it does not
support fault tolerance for the base exchange (or UPDATE) itself.

So it in the absence of a better solution, I would say yes.

> * Is it complete or does it need more work?

Baris is working on bug ids 592177 and 592125.

> * Who will maintain and develop it?

Baris completes the existing bugs and then I'll start maintaining it.

-- 
Broadcast as fall-back mechanism when no HIT->IP
https://bugs.launchpad.net/bugs/619332
You received this bug notification because you are a member of HIPL core
team, which is subscribed to HIPL.

Status in Host Identity Protocol for Linux: New

Bug description:
If the hip daemon can't resolve an address with hip_map_id_to_addr, it tries to broadcast an I1 message using standard interfaces.

This fallback mechanism is in my and Renes opinion useless and should be stripped out.

The cause of failing in my particular case was that I mounted /etc/hip/hosts with fuse and the fopen function failed to open it, even though hipd had root rights.