Brian E Carpenter <[email protected]> wrote: > Thanks Michael, we will wait a few more days before rolling up all > comments received. I am fine with most of your suggestions. A few > things caught my eye:
Cool.
>> 3.5.4.4: QUERY re: The relayed discovery message MUST have the same
>> Session ID as the incoming discovery message and MUST be tagged with
>> the IP address of its original initiator (see Section 3.8.4).
>>
>> I thought we were adding something about Link Local addresses here?
> What was the point there? (Clearly, discovered link-local addresses
> MUST NOT be sent on to another interface, is that it? But that affects
> the Discovery Response process, not the relay process. Must check my
> code, too...)
I think that's the point. Should we even relay discovery messages from LL
origins?
>> 3.5.5: re: The details, including the distinction between dry run and
>> an actual configuration change, will be defined separately for each
>> type of negotiation objective.
>>
>> I would very much like it if dry-run/real-run request was
>> standardized. This would make external auditing/debugging (such as
>> via network sniffer) much easier to see.
> Hmm. That needs some thought. I thought that the semantics of this was
> very hard to capture in a generic way.
> (One way would be to add a new flag value, so that an objective could
> be labelled F_NEG for negotiation and F_NEG_DRY for dry-run
> negotiation. That has a great advantage - it could be retrofitted any
> time, and can be rejected with an M_INVALID by a node without dry-run
> capability.)
I very much like this.
>> 3.8.6, about:
>>
>>> If a node receives a Request message for an objective for which no
>>> ASA is currently listening, it MUST immediately close the relevant
>>> socket to indicate this to the initiator.
>>
>> if the time sequence is: initiator ----M_DISCOVERY---> responder
>> (GRASP core) (UDP)
...> pass details to ASA
>> initiator<----M_RESPONSE----- ASA (TCP)
initiator-----M_REQ_NEG-----> ASA (same socket)
>>
>> then, according to above, why would an ASA have responded in the first
>> place if not be the right ASA?
> This covers the case where the ASA crashes at the critical moment -
> without this provision (depending on implementation details) the socket
> would be left hanging. Also consider that discovery results can be
> cached, so there might be a real time gap between the M_RESPONSE and
> the M_REQ_NEG, giving more chance that the ASA crashes or even exits
> cleanly.
So, are you saying that on some systems that the ASA could crash without
closing the socket that is opened for the M_RESPONSE?
>> Can we please have an example for M_FLOOD?
>>
>> Is this valid:
>>
>> [M_FLOOD, 124567, fe80::1234, 27, [[O_IPv6_LOCATOR, fe80::1234,
>> IPPROTO_UDP, 500]], ["ACP", flags, 1, ["bootstrap-okay"]]
> I think so, but I'll need to run it through my primitive validation
> chain...
okay, I want to make sure that I understand it.
>> Could an O_DIVERT occur in an M_FLOOD?
> Not in the current syntax, and I'm not sure why we'd need it.
I don't think we do, but I'm just asking random questions as to why not...
>> Can we have more than one locator option?
> No. That is a feature - if you embed multiple objectives in a single
> M_FLOOD, they are all associated with the same locator option. If
> that's a problem, now would be a good time to say so ;-).
I think that we physically can, it's an object inside an array.
Could we have an IPv4 and an IPv6 address? Or a UDP and a TCP locator, or...?
I'm thinking about how to construct the ACP neighbour awareness M_FLOOD such
that it can also carry the Proxy locator. I think it's probably not a
problem, as the locator can be the Proxy locator, and the ACP is implicitely
port-500 IKEv2, except that I'm reading the ACP document, and see that
actually there are many options for ACP security, but I haven't gotten that
far yet.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
