Re: 63 - extensibility and payload

 

> >
> >
> >- about 4.4: if/when we'd like to extend the mechanism, two things
> >seem to be interesting:
> > - the capability to move to another addresses (than the addresses in
> >   the IP header of the message), for instance for network controlled
> >   mobility.
> > - the capability to limit the update to a SA set (i.e., partial update).
> >Both will be easier with a payload...
> >  
> >
> 
> I agree that there are potentially interesting extensions,
> such as some kind of network control or limiting the SA
> set. As we have decided earlier, these are indeed future
> extensions and not a part of the initial base RFC.
> 
> But lets talk about what design is best to accommodate for
> such future extensions. In both cases that you mention,
> it seems that the addition of a payload (with appropriate
> previous capability negotiation) does the job. For instance,
> if we would like to design a "limited SA set update" feature,
> then in the IKE init phase we can find out if both peers support
> that. Then, if this particular movement is a limited update,
> we can include a new payload to that effect in the IKE
> exchange that tells the peer about the move.
> 
I agree that the new payload is the way to go. 

-mohan

> Creating such payload now, however, would change the
> design quite a bit and would imho make it hard to support
> NATs.
> 
> So, I would suggest that there are no text changes needed
> for the current document.
> 
> --Jari
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike