> >- Section 4.5
> > - What is the use of "NO_ADDITIONAL_ADDRESS"
> > notification ? At least i did not see any
> > description/hint of how one would use it.
>
> Missing text, I think. Section 4.5 or 5.3 should
> include something along the following lines:
>
> The ADDITIONAL_*_ADDRESS notification MUST be used
> when there's more than one address to be communicated
> to the peer. The NO_ADDITIONAL_ADDRESSES notification
> MUST be used when there is only one address, and the peer
> was previously informed of multiple addresses. As a result,
> NO_ADDITIONAL_ADDRESSES notification is not needed
> in the initial IKEv2 exchange, and the ADDITIONAL_*_ADDRESSES
> notification is needed in the the initial exchange only if there
> is more than one address.
This is already described in Section 5.3, but I agree, the text
perhaps needs some clarification..
> > - What is the use in adding NO_NATS_ALLOWED along with
> > ADDITIONAL_ADDRESS notification ? The receiver of
> > ADDITIONAL_ADDRESS takes it from the notification payload
> > and not from the IP header. Is it just that you want to
> > include NO_NATS_ALLOWED with all possible notifications ?
> > But section 4.8 allows only with IKE_SA_INIT and UPDATE_SA
> > _ADDRESS and ADDITIONAL_ADDRESS. In the IKE_SA_INIT and
> > UPDATE_SA, you take from the IP header and hence it makes
> > sense. Why do we need it for ADDITIONAL_ADDRESS ?
>
> I can't answer this. Pasi?
Because just like in the IKE_SA_INIT case, the notifications
contain addresses _in_addition_ to the one used in the IP header.
So we need NO_NATS_ALLOWED to protect the one in the IP header.
(We could change it so that all the addresses were in
ADDITIONAL_*_ADDRESS notifications, but this way it's more
uniform treatment IKE_SA_INIT vs. INFORMATIONAL, and NAT-T
vs. NAT prohibition.)
> > - The VPN gateway may have a single address but the client
> > may have multiple addresses. In that case it is okay if it
> > does not send ADDITIONAL_ADDRESS notification but it needs
> > to process one from the client. The last paragraph states
> > something different.
>
> Agreed, this is an issue. I think we wanted to say that clients that
> do not intend to use more than one address do not have to send
> ADDITIONAL_*_ADDRESS notifications. But they still need to be able
> to handle them. This is a part of the basic mobike protocol that
> devices supporting this rfc-to-be should support.
The text actually says that
"a simple "VPN gateway" that has only a single address, and is
not going to change it, does not need to send or understand
ADDITIONAL_*_ADDRESS notifications.
This is correct: the responder in this case does not have to
understand ADDITIONAL_*_ADDRESS notifications because the only time
it would use the information is when its own address changes. Or
in other words, even if it did understand them, it would not make
any difference since the information would not be used for anything.
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.