Re: [shim6] [nbs] I-D Action:draft-xu-name-shim6-00.txt

[mingzx <[e-mail]>]

Thanks for this feedback and it is very valuable to me :)
The materials in this email will be included in draft-01. 


On 2010-10-17 12:06:05，"Brian E Carpenter" <[e-mail]> wrote：
>> Abstract
>> 
>>    This document describes and defines shim6 as a mobility solution for
>>    name-based sockets.  
>
>My most general comment is that I think the draft should explain both
>how NBS works in the original shim6 scenario (multihoming without
>mobility) and then how it also works in the mobile case. I think
>it's a very neat trick if it really does extend shim6 to support
>mobility, but let's not forget the basics.
In the multihoming scenario, the following two cases may happen exclusively:

   1.  A subset but not all of the host's addresses becomes invalid.

   2.  All of the host's addresses become invalid.

In the first case, REAP works as its normal way as is defined in RFC
5534.  NO_LOC state will not be reached and the DNS will not be
queried.  With the presence of NBS, name is used as ULID instead of
IP and all addresses are treated equally.  NBS will not experience
the situation that and the connection must be terminated as the
address used as ULID becomes invalid.  Apart from the change to ULID,
Shim6 just works as is specified in RFC 5533 to provide multihoming.

In the second case, the original Shim6 will immediatelly terminate
the connection when all the addresses becomes invalid (or may be
earlier if the ULID is not the last one which becomes invalid) while
the modified Shim6 will first transmit to the NO_LOC state and breaks
the connection when timeout.  This means that NBS will preserve the
connection for a NO_LOC timeout interval even if there will no longer
be any address to use.  While this approach may lead to the holding
of the system resources when not necessary, it does have the advantage
that the connection can be recovered if the host achieves a valid
address during the NO_LOC period.
Does it make sense?
>
>> 3.1.  Introduction
>...
>>    The traditional Shim6 defined in RFC5533 [RFC5533] does not aim to
>>    solve mobility problem, so changes need to be made to the existing
>>    Shim6 protocol.  One of the reasons for not supporting mobility is
>>    that Shim6 uses a specific IP address as the identifier of the upper
>>    lay protocol.  To avoid confusion, communication must be stopped when
>>    this IP address becomes unavailable.  
>
>Small but important change: unavailable ==> invalid. You say this correctly
>later. "Unavailable" is confusing, since it might be understood to mean
>"unreachable"; actually it's quite normal that the ULID goes unreachable.
I have made it correct. Thank you.
 
>> 4.1.1.  Brief overview of changes
>...
>>    Name Based Sockets suggest using the name of a host as the
>>    identifier.  This solves the above problems, as a name is valid for
>>    as long as a host wishes it to be. 
>
>I don't think that's accurate. I think it would be accurate to
>say "a name is valid for as long as it exists in the DNS."
>If a name vanishes completely from the DNS, it seems that it is
>just as invalid as an expired IP address; it is simply a much
>rarer event.

I think this relates to the semantic of name in the name based sockets.
The DNS is used to provide NBS with a mobility solution but NBS does not 
require that the name depends on DNS. Even if a name vanishes completely
from the DNS, it still can be used by NBS to identify a session (through name exchange) 
and further be used by NBS+Shim6 to get multihoming. 

>On a related point, I think that you need a discussion somewhere
>of the latency for DNS updates to propagate, and how that affects
>the speed of recovery of a mobile connection. This point might
>make or break this whole solution. If the time to get an updated
>DNS RR is greater than the TCP session timeout, there's a problem.
 
Yes, this is definitely important. We are doing DNS investigation as
well as prototype test to see how DNS affects the recovery of a mobile
connection. I will back to you when I get more details.
 
 
>> 5.  Security Considerations
>
>The security of shim6 depends on using HBA/CGA addresses (including
>the initial ULID). How do we get equivalent security here?
>Is secure dynamic DNS update plus DNSSEC sufficient?

 
One trivial way to get equivalent security is to let NBS use HBA/CGA addresses. 
However, NBS was not designed to be dependent on HBA/CGA addresses and it might
not be the way we want to go. I'm not quite sure about whether secure dynamic DNS
update plus DNSSEC sufficient to provide equivalent security. We' are doing
investigation on this topic. Please let me know if you have any suggestion.
 
Regards
Zhongxing Ming