Re: [nbs] NBS and TCP connection identification

Hi Christian,

First of all I'm new to the list so maybe this has been asked already but hopefully somebody could clarify also to me.

How will a host with a RFC1918 address be able to synthesize its name or will all RFC1918 hosts have the same name? How will NBS separate these hosts or is it assumed that server will always sees the same name? Or do the end hosts see different names e.g. server sees the synthesized name of NAT and client sees the name of RFC1918?

If there was a host at certain IP A (obtained via DHCP) with synthesized name A when the next host (different) gets the same IP A from DHCP will it have the same name A? What should the peer be able to determine from this name and how will it know that it is different or same instance as the previous?

 Regards,
   Jan

On Oct 12, 2010, at 7:58 PM, Christian Vogt wrote:

> 
> You wrote:
> 
>>> Needless to say, if the initiator does not provide a name -- e.g., because it does not have a name registered in the DNS --, the responder would generate a name for the initiator based on the initiator's IP address.  Such a "synthesized" name does not have to be verified; it already provides the same level of security that we have today.
>> 
>> It isn't clear to me that synthesized names are needed. 
>> NBS APIs could instead continue to provide, in their binary format, addresses found in session originating packets, and let application ignore them if they aren't interested.
> 
> Remi:
> 
> The reason why I think we do need synthesized names is because of their semantics:  They name the host that was located at the encoded IP address at the time of session initiation.  Unlike the semantics of an IP address, which can name the host that /currently/ is located at the address, a synthesized name could be stable across a session.
> 
> Does this make sense?
> 
> - Christian
> 
> _______________________________________________
> nbs mailing list
> nbs@ietf.org
> https://www.ietf.org/mailman/listinfo/nbs