Re: [renum] Working Group Last Call: draft-ietf-6renum-gap-analysis-03.txt

Hi, Marc & Brian

Thanks for your comments. Please see inline.

> -----Original Message-----
> From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On Behalf Of
> Brian E Carpenter
> Sent: Tuesday, September 18, 2012 9:07 PM
> To: Marc Lampo
> Cc: renum@ietf.org
> Subject: Re: [renum] Working Group Last Call:
> draft-ietf-6renum-gap-analysis-03.txt
> 
> Marc,
> 
> On 18/09/2012 08:54, Marc Lampo wrote:
> > Hello (and sorry to jump in so late, but as I just changed employer ...),
> >
> > my remark is about impact of renumbering on IPSEC VPN definitions.
> > In my opinion this area is not addressed (enough).
> >
[Bing] In previous mails, Di Ma also pointed out this issue, and proposed some texts. Thank you for pointing it out again, then it is obvious that the IPsec renumbering issue would be probably cared by many people. We'll add some more description accordingly.

> > I understand that, via a reference to RFC5887 these is a suggestion to
> > define addresses on either side of an IPSEC VPN via DNS.
> > One element is that in practice, not all devices "out there" (some
> > very widely used) are not capable of defining the valid addresses on
> > an IPSEC endpoint via DNS.
> 
> True, that's an implementation and deployment gap, not a protocol gap.
> All we can do in the IETF is document this kind of gap, since we don't
> control implementations.
> 
> >
> > The second element is about the DNS aspect itself.
> > Suppose there is a site-to-site VPN between organisations A and B.
> > Suppose organisation A is capable of defining "valid addresses behind
> > VPN endpoint" via DNS.
> > Problem is that device at organisation A needs access to a NS that
> > "knows" about internal addresses at organisation B.
> > But if organisation B renumbers its internal network !
> > How can DNS server accessible/used by VPN endpoint at organisation A
> > know about new addresses in an automatic way ?
> 
> Only if B publishes the appropriate AAAA records in global DNS. Of course
> B must also use appropriate DNS TTLs and follow the RFC 4192 overlap
> procedure. Then when the IPsec SA breaks, the VPN software will retry
> and find the new AAAA record.
> 
> Nothing works if people don't use the global DNS correctly, due to misguided
> belief in security by obscurity.
> 
> > Because there is so little about this subject, in the present version,
> > I think it is not addressed enough.
> > Either explicitly, in a paragraph firmly stating recommendations and
> procedures;
> > or in section 9, Gaps considered unresolvable, where it can be added
> > why this is a problem and what admins will have to do manually, if
> > they renumber.
> 
> I think we need to separate out implementation and deployment
> recommendations,
> which are in scope for an Ops Area WG, even if we need to add a goal to
> the WG Charter.
> 
[Bing] For the detailed gap analysis you proposed above, I generally agree with Brian, we need to distinguish the protocol gaps and implementation gaps.
For the recommendations, I think we can consider to add some description in draft-ietf-6renum-enterprise-scenarios, which contains BCPs for renumbering as an important part of the draft.

> Regards
>     Brian
> 
> > Kind regards,
> >
> > Marc Lampo
> >
> > On Thu, Sep 6, 2012 at 6:17 PM, Howard, Lee <lee.howard@twcable.com>
> wrote:
> >> We are requesting a Working Group Last Call on this document.  Please
> review and provide comments before September 19, since this may be the final
> review of this document.
> >>
> >> Thanks,
> >>
> >> Lee
> >>
> >>
> >>> -----Original Message-----
> >>> From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On
> Behalf
> >>> Of internet- drafts@ietf.org
> >>> Sent: Monday, September 03, 2012 11:38 PM
> >>> To: i-d-announce@ietf.org
> >>> Cc: renum@ietf.org
> >>> Subject: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt
> >>>
> >>>
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >>>  This draft is a work item of the IPv6 Site Renumbering Working Group of
> the IETF.
> >>>
> >>>       Title           : IPv6 Site Renumbering Gap Analysis
> >>>       Author(s)       : Bing Liu
> >>>                           Sheng Jiang
> >>>                           Brian Carpenter
> >>>                           Stig Venaas
> >>>       Filename        : draft-ietf-6renum-gap-analysis-03.txt
> >>>       Pages           : 20
> >>>       Date            : 2012-09-03
> >>>
> >>> Abstract:
> >>>    This document briefly introduces the existing mechanisms could be
> >>>    utilized by IPv6 site renumbering and tries to cover most of the
> >>>    explicit issues and requirements of IPv6 renumbering. Through the gap
> >>>    analysis, the document provides a basis for future works that
> >>>    identify and develop solutions or to stimulate such development as
> >>>    appropriate. The gap analysis is presented following a renumbering
> >>>    event procedure clue.
> >>>
> >>>
> >>>
> >>>
> >>> The IETF datatracker status page for this draft is:
> >>> https://datatracker.ietf.org/doc/draft-ietf-6renum-gap-analysis
> >>>
> >>> There's also a htmlized version available at:
> >>> http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-03
> >>>
> >>> A diff from the previous version is available at:
> >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-6renum-gap-analysis-03
> >>>
> >>>
> >>> Internet-Drafts are also available by anonymous FTP at:
> >>> ftp://ftp.ietf.org/internet-drafts/
> >>>
> >>> _______________________________________________
> >>> renum mailing list
> >>> renum@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/renum
> >> Lee Howard
> >> Director, Network Technology
> >> Time Warner Cable
> >> (703) 345-3513
> >> 13820 Sunrise Valley Drive, Herndon VA 20171
> >>
> >>
> >>
> >> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for the
> use of the individual or entity to which it is addressed. If you are not the
> intended recipient of this E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be unlawful. If you
> have received this E-mail in error, please notify the sender immediately and
> permanently delete the original and any copy of this E-mail and any printout.
> >> _______________________________________________
> >> renum mailing list
> >> renum@ietf.org
> >> https://www.ietf.org/mailman/listinfo/renum
> > _______________________________________________
> > renum mailing list
> > renum@ietf.org
> > https://www.ietf.org/mailman/listinfo/renum
> >
> _______________________________________________
> renum mailing list
> renum@ietf.org
> https://www.ietf.org/mailman/listinfo/renum