Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05

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

Hi, Ted

Many thanks for your review, it would be helpful to refine the draft. Please see replies inline.

Best regards,
Bing

From: Ted Hardie [mailto:[e-mail]]
Sent: Friday, April 12, 2013 6:51 AM
To: [e-mail]; [e-mail]
Subject: Review of draft-ietf-6renum-gap-analysis-05

I have been selected as the Applications Area Directorate reviewer
for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:draft-ietf-6renum-gap-analysis-05
Title: IPv6 Site Renumbering Gap Analysis
Reviewer: Ted Hardie
Review Date: April 11, 2013

Summary: This document is basically ready to be published as an Informational draft.  There are minor issues which the authors may wish to address before final publication.


Minor Issues:

The document currently motivates its work with the following statement:

   If IPv6 site renumbering continues to be considered

   difficult, network managers will turn to Provider Independent (PI)

   addressing for IPv6 to attempt to minimize the need for future

   renumbering. However, widespread use of PI may create very serious

   BGP4 scaling problems. It is thus desirable to develop tools and

   practices that may make renumbering a simpler process to reduce

   demand for IPv6 PI space.

A citation for this would be useful.  It might also be worth it to
highlight other potential risks--for example, the widespread deployment
of ULAs, which do not admit of aggregation, or the deployment of


[Bing] Ok, thanks for the suggestion. We'll include the reference on BGP4 scaling issue, as well as considering whether there are other potential risks.

But for the specific ULA problem, it might be different. ULA is intended to be used within a certain scope, normally, within an enterprise network. So it won't bother the global routing scalability.

In fact we suggest to use ULA along with PA in enterprise to avoid some renumbering or to make internal communication more stable when switching global prefixes. It was documented in the recently published 6renum RFC6879 (Please see section 4.1)



address translation technologies which make referral more difficult.  I note
that RFC 5887 included some of these issues.  If the intent is to reference
those from RFC 5887, I note that  the document currently says that it




"starts from existing work in [RFC5887],

[I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references
to these documents are informative.  If the document is meant to be an extension,
rather than a replacement, such that these documents must be read to get the full

picture, than a normative reference may be better.



[Bing] These documents are important input for the gap analysis draft. They indeed have not a few crossed content, but our intention on the gap draft was different, so it is neither extension nor replacement.

RFC5887&draft-thinkabout are more comprehensive analysis/guidelines on IPv6 renumbering issue; RFC4192 emphasizes on a "make before break" prefix switching operation.

This gap draft  addresses the IPv6 enterprise scenarios described in RFC6879, and focusing on identifying what is missing to make renum more automatic and less error-prone.


For the session survivability section, a reference to RFC 6724 may be useful, so
that those adding new global addresses understand how the application API to determine


which address is used with interact with the addition of new addresses (if there
is a specific draft or other treatment of that topic, that would be even better,
but I am not personally aware of one).



[Bing] OK. Address selection is indeed important.


In section 6, the document currently says:


   When nodes in a site have been renumbered, then all the entries in

   the site which contain the nodes' addresses must be updated. The

   entries mainly include DNS records and filters in various entities

   such as ACLs in firewalls/gateways.

This appears to imply that these updates must take place after the renumbering
event, but this is variable.  ACLs and filters may well be updated in advance;
DNS may be updated concurrently or post facto.  A rewording to highlight that

this is variable by record type may be useful.



[Bing] Ok, thanks.

Section 9.2, in the bullet entitled "DNS data structure optimization"
The discusses a DNS feature proposed but declared historic. I don't think it

identifies the related renumbering gap in a way that is useful for a naive
reader.  If it cannot be reworded to focus on the gap, I suggest it be
removed.


[Bing] When we wrote the draft, we considered if the IPv6 DNS record could be structured as separating prefix and suffix, that would be very helpful for renumbering. Because in IPv6, most of the time we just change the prefixes rather than the whole addresses.

We found A6 has the similar feature, but it has been moved to historic. However,  the idea of separating prefix and suffix is still considered valuable, but there might not  be able to develop a new DNS record in a short time, so we name the idea as "DNS data structure optimization" and put it into "gaps considered unsolvable".

We can add some minor texts to explain the intention.

In section 9.4, the document says:

      For application layer, as [RFC5887] said, in general, we can

      assert that any implementation is at risk from renumbering if it

      does not check that an address is valid each time it opens a new

      communications session.

This might be reworded to  include or focus on session resumption, rather than
new communications sessions.  From an applications perspective, the laptop
"sleep" function seems to be one of the bigger risks of this.


[Bing] Ok, thanks.

Nit:

For me personally, section 6.1 seemed needlessly pessimistic.

[Bing] It is sad but true. And we are curious about how much operational issues there to prevent DDNS widely deployed in real networks.

If possible, we might consider to make a dedicated draft to talk about this issue in the future.