Subject: Re: Last Call: draft-carpenter-renum-needs-work (Renumbering still needs work) to Informational RFC

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 10 Sep 2009 12:05:30 +0200

On Wed, Sep 09, 2009 at 06:12:20AM -0700,
 The IESG <[email-masked]> wrote 
 a message of 23 lines which said:

> The IESG has received a request from an individual submitter to consider 
> the following document:
> 
> - 'Renumbering still needs work '
>    <draft-carpenter-renum-needs-work-03.txt> as an Informational RFC

It is a very important subject for the Internet. I've read the
document, and I believe it is complete and correct (the title
summarizes the conclusion quite nicely). (I've specially focused on
the DNS section.)

Unlike what some people say (for instance in the discussions at fora
like the RIRs), renumbering IP addresses *is* painful for the normal
and ordinary sites.

I support the publication.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Sep 2009 13:19:43 +0200

Dear Authors & IESG,

Congratulations for providing us a comprehensive and interesting piece
of work that describes an abundance of issues that face administrators
who need to renumber their networks. 

I have several comments about this draft.  At a high level, I wonder
whether in fact some of the information is worthy of a deeper review,
perhaps in follow-on work.  The conversation on DNS Pinning alone seems
to warrant its own effort.  I can see that there must have been great
thought about how to organize information, considering that security
considerations run high when taking any configuration from the network,
even if that is as simple as a DNS query, as described in the doc.

In Section 5.1.1, the authors discuss an ambiguous behavior involving
DHCPv6 versus SLAAC and the go on to say:

>    Until this ambiguous behaviour is clearly resolved by the IETF,
>    operational problems are to be expected.  Also, it should be noted
>    that on an isolated LAN, neither RA nor DHCPv6 responses will be
>    received, and the host will remain with only its self-assigned link-
>    local address.  One could also have a situation where a multihomed
>    network uses SLAAC for one address prefix and DHCPv6 for another,
>    which would clearly create a risk of inconsistent host behavior and
>    operational confusion.
>   

Would the authors care to clarify what operational problems could be
expected regarding the ambiguity, and what the risk of inconsistent host
behavior would be, and what recommendations they would have (if any) to
resolve those issues?  I feel teased ;-)

In Section 6.1 the authors discuss SHIM6.  I draw their attention to a
paper given by Richard Clayton at this year's Workshop on Economics and
Information Security (WEIS09) which can be found at the following URL
that discusses economic road blocks to deploying SHIM6:
http://weis09.infosecon.net/files/135/index.html.  My suggestion is that
this work be considered as a reference.  During his presentation, Dr.
Clayton suggested that perhaps we have Economics Considerations in our
protocol specifications.  While I don't think that's appropriate, the
analysis is enlightening.

I also believe that there is an elephant that remains in the living
room, with regard to Section 6.  There is no mention of the work being
considered within the RRG, or that of the LISP WG.  A principle benefit
of LISP and certain similar approaches is the near complete obviating of
the need to renumber.  Having bashed my own head on this problem
numerous times, I think it's important to ask the question of whether we
should just stop asking networks to do so, and architect/engineer
accordingly.

Thanks again for your efforts,

Eliot

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 10 Sep 2009 22:00:40 +0900

> It is a very important subject for the Internet.

Agreed.

However, scope of the document is seemingly wrong.

Surely, it's important to document how wrongly IPv4 and IPv6 was
architected against renumbering.

But, it is simply impossible to add work to IPv4 or IPv6 to make
renumbering feasible.

What we need for the future Internet is a clean slate approach to
define new IP, definitely not toooooo complicated IPv6.

That's another reason not to deploy IPv6 but to migrate from IPv4
directly to something else.

Mean while, NAT, including End to End NAT, which is transparent end
to end, will help us to preserve IPv4 address space for next 10 or 20
years.

> I've read the

As is discussed recently in DNS WGs that making DNS message size
larger with EDNS is virtually impossible, it is virtually impossible
to change widely deployed improper implementations.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Sep 2009 10:31:24 +1200

Masataka,

You say: "scope of the document is seemingly wrong."

Well, the scope of the document is to discuss how actual networks
running IPv4 and IPv6 can deal with renumbering. That can't be "wrong";
it is simply what we chose to write about.

If you'd like to start a thread about IPng, can you use a different
subject header please?

Regards
     Brian

On 2009-09-11 01:00, Masataka Ohta wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 11 Sep 2009 08:29:24 +0900

Brian E Carpenter wrote:

> running IPv4 and IPv6 can deal with renumbering.

So, it's a wrong scope.

> That can't be "wrong";

It can be wrong.

The reality, instead, is that actual networks running IPv4 and IPv6
***CAN'T*** deal with renumbering, because of their inertia.

> it is simply what we chose to write about.

I'm saying that is a poor selection only to produce poor documents.

If you don't mind, feel free to produce the poor documents.

> If you'd like to start a thread about IPng, can you use a different

I'm afraid, considering the so poor quality of IPv6, IETF has already
lost power to produce IPngs.

						Masataka Ohta

---

From: Eliot Lear <[email-masked]>
Date: Fri, 11 Sep 2009 09:07:35 +0200

Masataka,

> ***CAN'T*** deal with renumbering, because of their inertia.

While I obviously have sympathy for the sentiment, I think your
statement is too strong.  I believe it would be better to say that end
users have an economic incentive to avoid having to renumber, and most
are able to make use of RFC 1918 / ULAs and NAT with attendant
consequences to avoid the effort involved.

Still, I would argue strongly for inclusion of a fuller discussion about
technologies that obviate the need to renumber.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Sep 2009 09:00:41 +1200

Eliot,

We'll respond in detail to your helpful comments in due course.
However,

> technologies that obviate the need to renumber.

The hypothesis of the document is there will always be circumstances in
which partial or complete renumbering is needed, whatever such technologies
may be available. We should maybe make that clearer in the Introduction.

    Brian

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 12 Sep 2009 10:41:37 +0900

> consequences to avoid the effort involved.

I mean the obstacle against renumbering is "inertia" of existing
implementations, which will not be modified regardless of whatever
RFCs published later.

The only chance to have deployable renumbering mechanism was in
early stages of IPv6 development. It's too late now. 

The next chance will be when yet another IPng will be developped.

						Masataka Ohta