draft-ietf-shim6-proto-06 : Sending R2 in I2-SENT state

[Sébastien Barré <sbarre@info.ucl.ac.be>]

Hi,

I have still a question regarding the proto draft. I'm sorry to post it 
so late, I was delayed in re-reading the draft in depth, and could not 
be present at IETF meeting. So, here is :

(p76) In section 10.4, it is stated that upon reception of an update 
request and if the state is I2-SENT or I2bis-SENT, we need to reply with 
an R2 then process the update. I agree with processing the update 
request, but I don't understand why to send an R2 : If the responder is 
in established state, it will anyway drop the R2. And I suppose that if 
the responder sent an update request, this implies that it is already in 
established state.

I suppose that you have a good reason of doing this, because I see in 
section 12.1 that in state I2-SENT, if payload is received, an R2 must 
also be sent (which I see equally as useless, since silently discarded 
by the peer). Also, in section 10.5, the same behaviour is defined. Can 
you explain the reason for this ?

btw,  in appendix B, the simplified state machine is inconsistent with 
the text, saying that in I2-SENT state, an I2 (not an R2) must be 
replied to payload extension header packets, because the peer probably 
has sent an R2 which was lost. This appears to me more appropriate than 
what is said in sections 10.4, 10.5 and 12.1.
otoh, the simplified state machine diagram in appendix B.1 agrees with 
the text (so disagrees with appendix B).

Sébastien.

--
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium