Re: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt

["Liubing (Leo)" <[e-mail]>]

Hi, Ran

Thanks a lot for the detailed clarification of the IPSEC renumbering issue. I think it is fully clear now.

But I think what Di and Marc argued is that, they might found in their cases, the FQDN ability was not easy to enable, which may caused by various deployment/implementation issues. Especially in the Not-well-managed networks, the issue may be common.
If I understood them correctly. I think we need to emphasize the IPSEC FQDN as a BCP in the draft-ietf-6renum-enterprise-scenarios, we can add some more description according to your detailed comments below.

So, may I ask Di and Marc's opinions about it?

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> RJ Atkinson
> Sent: Thursday, September 20, 2012 3:12 AM
> To: [e-mail]
> Subject: Re: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt
> 
> 
> Earlier Di Ma wrote:
> > Yet as a document providing a basis for future works that identify
> > and develop solutions or to stimulate such development as appropriate,
> > this draft might make IPSec Security Association (SA) management
> > included, considering IPSec SA is a kind of IP address oriented
> > "connection" that cannot function after the change of the involved
> > IP addresses, which means extra configuration of SA parameters
> > is inevitable after network renumbering.
> 
> In general, the above is NOT correct with regard to IPsec.
> 
> I wrote the IPsec specs (e.g. RFC-1825 et seq) and was,
> for a time, IPsec WG Co-Chair.  I'm also the person who
> insisted upon having non-IP-address identities defined
> in the specs, not because of renumbering, but because of
> the more general issue of different users wanting to use
> different identity types.
......