Lakshminath Dondeti wrote:
> When the initiator receives an INFORMATIONAL request
> containing ADDITIONAL_ADDRESS, it stores the information and
> also determines whether the currently used path needs to be
> changed (for instance, if the currently used address is no
> longer included in the list); if it does, the initiator
> proceeds as described in the previous section.
>
> <LD> I must say that I don't like overloading the Notification
> payload with IP addresses. IKEv2 uses ID payloads for this
> purpose, why not use those? </LD>
IMHO the purpose of ID payloads is very different from this
one (they're not usually IP addresses, and even when they are,
they're not necessarily addresses that actually appear in any
packets). And besides, there are cases when the same message
needs to contain both ADDITIONAL_ADDRESS and ID payloads.
But we could of course promote ADDITIONAL_ADDRESS from a
Notification to a real "top-level" payload type. Any comments
from others about this?
The main difference seems to be that payload type field is only
8 bits while Notification type is 16 bits. And Notification
status types are already overloaded for a dozen different
purposes (some of which might have deserved their own "top-level"
payload type, BTW), so keeping this as a Notification would
at least be in line with the IKEv2 base spec :-)
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.