[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-ietf-shim6-proto-05.txt {2}

marcelo bagnulo braun schrieb:



El 08/10/2006, a las 17:09, Deguang Le escribió:


agree
basically the usage of the BROKEN flag is intended for when the host knows thanks to local information that a locator is temporarily unavailbale/unreachable, so it can mark it as such, so that the peer doesn't use it for communicating. 


I agree with you, it is a good way to deal with the temporary failure of
locator using the BROKEN flag.
However, if the locator is permanently unavailbale/unreachable say due
to mobility or rehoming, I think it is not necessary to keep the
unavailable locator in the locator set. Right?
both approaches are possible and i guess that your viewpoint makes more sense
As mentioned in the other email, another option would be to remove from the locator set using a Update message, but i guess this option is cheaper in terms of processing (cheaper security checks) 


As for security check, I am not familiar with security issue, so I don't
know why the Locator Preference option need not verification check. ^-^

Does anyone provide some explanations about it? Thank in advance.
to change the locator set you need to include security information either HBA or CGA. In the HBA case, this is a hash calculation and in the CGA is a public key operation. OTOH, to change the preferences, only a cookie is used, so it is much cheaper. This is so because changing the locator set may result in all types of redirection attacks from off path attacker. However, changing the preferences can only be done by on path attacker and it would result in potentially changing the locator used (if the peer takes into account the preferences). Hence the protection of one operation is less than the other. 
Thank you very much for your detailed explanations. :-)
Besides, the above explanation for "TEMPORARY" is still not clear for me. What are the more stable addresses and what are the less stable addresses?
the goal here is that if the host knows that there are some addresses that may change rapidly, it can mark them as such, so that the peer use more aggresive failure detection mechanisms on that address. 


I think it is an interesting usage although it is not easy to determine
which addresses belong to more stable or less stable. :-)
In the case of MIP a HoA is a more stable address and a CoA is a less stable address 

In my own veiw, I don't think the HoA is the more stable address and the
CoA is the less stable address because the mobile node may stay at any
place including the home network or foreign network at any time.
For example, a mobile node may access to the Internet through some
foreign network, then it may moves between the foreign networks, which
are far from the home network. In this case, the HoA may never be usable
during the whole communication period. Therefore, we could not regard the HoA as the more stable address. Right? 



i don't think so...
the Hoa is always reachable because the Home Agent would forward the packets delivered to the HoA (the performance would be worse though) The CoA is only usable while the node is in the visited network, hence the HoA is much more stable than the CoA even in the scenario that you describe, agree? 


Thank you very much!
I think I can understand the situation you described, namely SHIM6 works together with MIPv6 and the SHIM6 of the MN uses some HoA as the current locator no matter the MN is attaching the correspondent home network or not. Right? ^-^
Base on this situation, your statements are right. However, I think, on one hand, the your described reachability of HoA is achieved through MIP mechanism not SHIM6 itself, on the other hand, although the MIP is appled together with SHIM6, it is still possible that the HoA may be unusable due to the failure of home link or home agent. Therefore, we still could not ensure that the HoA is always reachable. 

In fact, my understanding about the criterion of choosing a HoA as the
current locator has some different to yours. I think the choice of
current locator for a shim6 host depends on if the locator (no matter
HoA or CoA) is currently associated with a interface of shim6 host and
is active. Only those active HoAs, which are associated with the shim6 host's interfaces, can be chosen for current locator. For example, if the SHIM6 host does not attach to a home network (link), then the SHIM6 protocol of this host should not choose the corresponding HoA as the current locator. This is the reason why I don't think the HoA is the more stable address. right? :-) 

Have a nice weekend!
Cheers,
Deguang
I think it is better if this draft could provides some special situations about them. Morever, I also can not understand how the TEMPORARY can be used to distinguish them.
The usage would be that it will include the Temporary flag when conveying CoA information in the locator set. 


As my above statements, I think it is not suitable to tag the CoA as
Temporary. Right? :-)


see above



Do you think that additional text is required to explain this?


Yes, I think these flags are very important in order to put the Locator
Preference option in real use, we need to formulate these flags'
functions and their usage (e.g. applied situations) more clearly.
I am ok with addin additional text for the broken flag since there is no text describing it... i am willing to include additional text on the temporary flag, but not sure what to include there though... 

Regards, marcelo



With best regards,
Deguang



Regards, marcelo


Cheers,
Deguang


Geoff Huston schrieb:


Hi,
This note starts the WG Last Call for comments on the three "base" Shim6 documents:
draft-ietf-shim6-proto-05.txt "Level 3 multihoming shim protocol" 
 draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator Pair Exploration Protocol for IPv6 
                                       Multihoming"

They can be found at:
   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- detection-06.txt
Please review the documents carefully, and send your feedback to the SHIM6 list. Please also indicate whether or not you believe that these documents are ready to go to the IESG for publication as a set of Proposed Standards.
This Working Group Last Call will end in two weeks, on the 12th October 2006 at 0800, UTC+10 


  Thanks,


        Geoff & Kurtis