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

From: Ted Hardie <[email-masked]>
Date: Thu, 11 Apr 2013 15:51:00 -0700

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

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.

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).

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.

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.

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.

Nit:

For me personally, section 6.1 seemed needlessly pessimistic.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 12 Apr 2013 03:00:54 +0000

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:[email-masked]]
Sent: Friday, April 12, 2013 6:51 AM
To: [email-masked]; [email-masked]
Subject: Review of draft-ietf-6renum-gap-analysis-05

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:

[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)

[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

[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

[Bing] OK. Address selection is indeed important.

[Bing] Ok, thanks.

[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.

      communications session.

[Bing] Ok, thanks.

Nit:

[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.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 15 Apr 2013 15:34:37 -0700

On Thu, Apr 11, 2013 at 8:00 PM, Liubing (Leo) <[email-masked]>wrote:

>  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:[email-masked]]
> *Sent:* Friday, April 12, 2013 6:51 AM
> *To:* [email-masked];
> [email-masked]
> *Subject:* Review of draft-ietf-6renum-gap-analysis-05****
>
> ** **
>
> Document:draft-ietf-6renum-gap-analysis-05****
>
> Review Date: April 11, 2013****
>
>
> 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****
>
> ****
> [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)****
>
> **
>
>
My feelings on ULAs are both largely unprintable and pretty well-known.
I'll spare you the re-iteration.

> **
> ****
> ** **
> "starts from existing work in [RFC5887],****
>
> 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.****
>
>
>
> Well, we don't have a category for "informative, but really important
context", so I leave it to you to pick.  I would personally likely choose
normative to highlight their importance.

> ****
> but I am not personally aware of one).****
>
> ** **
>
> [Bing] OK. Address selection is indeed important. ****
>
>
>
> ****
>    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****
>
> 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.
>
>
> The discusses a DNS feature proposed but declared historic. I don't think it****
>
> ****
> [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.****
>
>
> Thanks.  I do think it should be clear that you are not attempting to
resurrect the A6 vs. AAAA argument.

>       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.
>
> ****
> [Bing] Ok, thanks.****
> 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. ****
>
> ** **
>
>   Thanks for your quick reply,

Ted Hardie

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Apr 2013 07:45:49 +0100

>> Well, we don't have a category for "informative, but really important context", so I leave it to you to pick.  I would personally likely choose normative to highlight their importance.
> 
> [Bing2] Ok, if normative could highlight the importance without implication of extension or replacement, then I think it is good. Thanks for the suggestion.

RFC 5887 and 4192 are Informational so cannot be normative, and the draft
is long-expired so cannot be normative.

Regards
   Brian

---

From: Barry Leiba <[email-masked]>
Date: Tue, 16 Apr 2013 08:27:38 -0400

> RFC 5887 and 4192 are Informational so cannot be normative

That's not true any more -- we've allowed downrefs to Informational
documents for some time now, if the community agrees, through a note in the
last call announcement, that they are necessary references.  All we'd have
to do is run a last call that specifically mentions them.

Barry

On Tuesday, April 16, 2013, Brian E Carpenter wrote:

> > [Bing2] Ok, if normative could highlight the importance without
> implication of extension or replacement, then I think it is good. Thanks
> for the suggestion.
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Apr 2013 13:35:15 +0100

> to do is run a last call that specifically mentions them.

Yes, I am aware of that, and it's a matter of judgement, but
since this draft is not in any sense a protocol specification
or a pseudo-BCP, I am not sure why it needs *any* normative
references, let alone downrefs. There is certainly no
process requirement for them.

   Brian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 16 Apr 2013 08:06:15 -0700

> process requirement for them.
I certainly agree that there is no process requirement, but there is a
potentially useful result.  When I see a document like this with 9
normative references (as it has now), I get the sense that those are the
ones which are needed context and that the informative ones are useful
additional information.  That maps to "Essential reading" and "Useful
additional information", which is pretty much the same mapping as
"Normative" and "Informative" have in a protocol spec.  It's not *exactly*
the same, I grant you, but it's an approximation.  My question about the
three listed as "starts from" might have been better phrased as:  are these
"Essential Reading" or "Useful additional information"?

regards,

Ted Hardie

> [email-masked]

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 16 Apr 2013 01:25:48 +0000

Hi, Ted

Just a couple of minor replies in line. Thank you.

From: Ted Hardie [mailto:[email-masked]]
Sent: Tuesday, April 16, 2013 6:35 AM
To: Liubing (Leo)
Cc: [email-masked]; [email-masked]
Subject: Re: Review of draft-ietf-6renum-gap-analysis-05

On Thu, Apr 11, 2013 at 8:00 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Ted

Best regards,
Bing

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

Minor Issues:

My feelings on ULAs are both largely unprintable and pretty well-known.  I'll spare you the re-iteration.

[Bing2] I might misunderstood your previous comment on ULA. Thanks for sparing the re-iteration :)

Best regards,
Bing

[Bing] Ok, thanks.

Thanks.  I do think it should be clear that you are not attempting to resurrect the A6 vs. AAAA argument.

      communications session.

[Bing] Ok, thanks.

Nit:

Ted Hardie

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Apr 2013 16:32:01 +0100

Ted,

> "Essential Reading" or "Useful additional information"?

IMHO, the RFCs are necessary reading for a complete understanding.
The I-D is far too expired for that, although there has been some
discussion of reviving its contents.

Of course, as an author I will follow whatever the WG chairs and AD
decide is the consensus - it's just that doing a second downref Last Call
for this document seems a bit OTT.

    Brian

---

From: Barry Leiba <[email-masked]>
Date: Tue, 16 Apr 2013 15:07:24 -0400

> it's just that doing a second downref Last Call for this document seems a
bit OTT.

Actually, as this doc is itself Informational, there are no downrefs.  We
can change any reference to normative, with no need for a second last call.
 That would only be needed if this doc were Standards Track or BCP.

Barry

On Tuesday, April 16, 2013, Brian E Carpenter wrote:

> > [email-masked] <javascript:;>> wrote:
> >
> >>>> [email-masked] <javascript:;> <javascript:;>

---

From: S Moonesamy <[email-masked]>
Date: Tue, 16 Apr 2013 12:28:38 -0700

Hi Brian,
>for this document seems a bit OTT.

Agreed.

I agree with the comments posted by Ted Hardie at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09296.html

RFC 2874 is a normative reference which is only mentioned in Section 
9.2.  The status of that RFC is Historic.

RFC 2894 is a normative reference.  It is referenced in Section 3.1 
(relevant protocols and mechanisms).  It is mentioned that the 
protocol is not widely used.  Should I read that RFC before reading 
draft-ietf-6renum-gap-analysis-05?

RFC 3971 is a normative reference in 
draft-ietf-6renum-gap-analysis-05.  It is only referenced in the 
Security Considerations section.

RFC 3956 is listed both as an informative and a normative reference.

Section 1 mentions that:

   "This document does further analysis and identifies the valuable and
    solvable issues, digs out of some undiscovered gaps, and gives some
    solution suggestions."

Should I read RFC 5887, I-D.chown-v6ops-renumber-thinkabout and RFC 
4192 before reading draft-ietf-6renum-gap-analysis-05?

Regards,
S. Moonesamy