--------------------

Lakshminath Dondeti (2005-07-08)

     Initiator                   Responder
    -----------                 -----------
     HDR, SK { N(ADDITIONAL_ADDRESS)+,
               N(COOKIE2) }  -->

                            <--  HDR, SK { N(COOKIE2) }

  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>

--------------------

Pasi Eronen (2005-07-12):

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 :-)

--------------------

Tero Kivinen (2005-07-12):

> 3.2  ADDITIONAL_ADDRESS notification payload
> 
>    Both initiator and responder can include ADDITIONAL_ADDRESS payloads
>    in the IKE_AUTH exchange and INFORMATIONAL exchange request messages;
>    see Section 2.2 and Section 2.4 for more detailed description.
> 
>    The Notify Message Type for ADDITIONAL_ADDRESS is TBD-BY-IANA
>    (16396..40959).  The Protocol ID field is set to one (1), and SPI
>    Size is set to zero.  The data associated with this Notify type is
>    either an IPv4 address or an IPv6 address; the type is determined by
>    the payload length.

I think it is better to take 2 different notification types for IPv4
and IPv6. Checking the lenght is bad, as then we cannot extend the
structure later by adding more information to the notification data.
The design draft asks this in the section 5.11, i.e. make the format
so we can extend in the future it with new data, like load balancing
weight (currently out of scope, but one of the possible future works).

--------------------

Pasi Eronen (2005-07-14):

Sounds OK to me; I'll change that to ADDITIONAL_IP4_ADDRESS
and ADDITIONAL_IP6_ADDRESS in -01.

--------------------

Pasi Eronen (2005-07-18):

Version -01 now has separate
notification payloads for ADDITIONAL_IP4_ADDRESS and
ADDITIONAL_IP6_ADDERESS. These are still notification payloads
(instead of "top-level" payloads), since it seems to be reasonably 
in line with base IKEv2 spec.

--------------------

Issue closed on 2005-07-25.

--------------------

Francis Dupont (2005-07-31):


=> I believe we should keep Notifications because this allows to
declare additional addresses in the second exchange. This can be used
for instance for the home registration BU/BA protection in MIPv6:
IKE runs over the care-of address but the SA pair is a transport mode
with the home address in the source traffic selector. The care-of address
is authorized because IKE exchanges include an implicit return routability
check, the home address is usually explicitly authorized through configuration
and/or the mobile node certificate, and the transport mode in Mobike I-D
applies...

--------------------