Frank Quick: If new wording is possible at this late hour it would be
preferable as a means of avoiding future confusion.

The sections I have identified that should be considered for change are:

In MIPv6 -24:

1.  Section 5.1, page 21:

   When IKE version 1 is used with preshared secret authentication
   between the mobile node and the home agent, aggressive mode MUST be
   used.  Similarly, the ID_IPV6_ADDR Identity Payload MUST NOT be used
   in IKEv1 phase 1.

might be revised to separate the sentences, as follows:

   When IKE version 1 is used with preshared secret authentication
   between the mobile node and the home agent, aggressive mode MUST be
   used.

   The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 1.  [a reference to the ipsec
   i-d would be useful here if appropriate]

2.  Section 11.3.2, page 113:

   o  In addition, for all security associations bound to the mobile
      node's home address established by IKE, the mobile node MUST
      include an ISAKMP Identification Payload [8] in the IKE exchange,
      giving the mobile node's home address as the initiator of the
      Security Association [7].

It is not critical, but I would suggest that "the IKE exchange" read "the IKE phase 2 exchange".

In the ipsec-06 draft, section 4.4:

There is no mention of any problem related to the use of ID_IPV6_ADDR except in the context of preshared keys, where it points out that the different addresses make the key lookup ambiguous.  I think another paragraph about the implementation issue, applicable to all phase 1 exchanges, should be added.  If this is done, a section reference might be added in the MIPv6 document as noted above.

I am probably not the best qualified to write this new section, but here is a cut at it, hoping that it will be of some use:

   o  During IKEv1 phase 1, the ISAKMP Identification payload cannot be
      of type ID_IPV6_ADDR.  Since IKEv1 does not protect the Source
      Address, IKE implementations typically compare an ID_IPV6_ADDR
      Identification payload to the Source Address, and abort if the
      contents do not match.  In IKEv1 phase 1, the Source Address must
      be the care-of address and the Identification payload must indicate
      the home address, therefore another Identification payload type
      must be used.

This should follow the current paragraph related to the preshared key issue. 

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

Vijay Devarapalli: I think the first two suggestions should be
adopted. I am not sure about the 3rd one.

Adopt the first two suggestions. I am not sure about the third
one. infact the third one is wrong. for id, we use FQDN/NAI in
Phase 1 and Home Address in Phase 2. 

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

Jari Arkko writes:

>>    The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 

Breaking the paragraph in two is fine.

>> 1.  [a reference to the ipsec
>>    i-d would be useful here if appropriate]

Maybe not, if there's no additional explanation in the
other draft either.

>> 2.  Section 11.3.2, page 113:
>>
>>    o  In addition, for all security associations bound to the mobile
>>       node's home address established by IKE, the mobile node MUST
>>       include an ISAKMP Identification Payload [8] in the IKE exchange,
>>       giving the mobile node's home address as the initiator of the
>>       Security Association [7].
>>
>> It is not critical, but I would suggest that "the IKE exchange" read 
>> "the IKE phase 2 exchange".

Right.

Seems like the third issue, the rationale behind not
using IPV6_ADDR in phase 1, has already been dealt with
in e.g. issue 305. I don't think we should add the
rationale to the RFC at this stage.

This leaves us with the first two modifications.

> adopt the first two suggestions. I am not sure about the third
> one. infact the third one is wrong. for id, we use FQDN/NAI in
> Phase 1 and Home Address in Phase 2.

He says phase 1, so the text might be ok. But I'm
not inclined to add new explanations. The draft is
clear in terms of what has to be done. What the rationale
was behind it is not so critical that we should
be adding stuff to the RFC at this stage.

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

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