Subject: Thoughts on the draft-hinden last call

From: Hans Kruse <[email-masked]>
Date: Sat, 01 Nov 2003 14:14:18 -0500

Here are my current thoughts on the last-call discussion going on regarding 
the unique local addressing:  It seems to me that three subjects are going 
around:

(1) There have been a few comments of the "we just don't need this type of 
address" kind.  I respect that point of few, and firmly disagree.  Further, 
I cannot agree with any of the scenarios that attempt to attach "they will 
cause damage" labels to local addresses; here is why:  We have sufficient 
needs/requirements/scenario descriptions to reasonably deduce that network 
managers today, tomorrow, and in the foreseeable future will be faced with 
requirements that they will choose to satisfy with some form of local 
addressing.  (The fact that many requirements can at some point in the 
future be addressed by better technical means does not change this 
statement).  The strength of the Internet is its flexibility and the fact 
that there is no "design police" constraining deployments.

If the WG defines a unique/near-unique address format for this purpose, we 
will at least know that the risk of prefix collisions is minimized, and we 
can recognize (and filter) these addresses if they leak.

Without this definition, one of two things will happen:  If we are really 
lucky, the network manager will pick the old site-local prefix.  Some 
applications will still "know" these as different, and may behave in 
unexpected ways, but we can at least recognize these addresses for what 
they are and filter them.  They cannot be traced back, and they are very 
likely not unique, creating all sorts of additional problems.

If the network manager instead hijacks a prefix, things get really bad.  If 
the hijacked addresses leak, you have to deal with them on a case-by-case 
basis, and they may collide with a legitimately assigned prefix, making 
debugging and filtering a nightmare.

All in all, I prefer to have a recognized prefix.

(2) The only technical issue seems to be address selection.  (BTW, if you 
are tempted to reply with "we don't know how to do this so we should not 
create this type of address", see (1) above).  We could attempt to write up 
suggestions for special handling of local addresses  in APIs and apps, 
mostly based on MAY and SHOULD.  On the other hand, if apps treat local 
addresses as global (which they are, just not routable beyond some point), 
these will work fine in the majority of the deployment scenarios where 
hosts have only one address.  The mixed/multiple addressing case is where 
failures will happen, but we may want to simply outline the issues and let 
network managers and/or app designers decide if/how they want to handle 
these cases. In any case, lets pick an approach, write the text, and move 
on.

(3) The registry setup seems to be the third issue.  I have very little 
expertise in this area, but from the technical end, I think the draft needs 
to at a minimum:

* require that IANA delegate the local prefix to one and only one registry;
* require that the agreement with the registry contain an escrow provision
* require that the agreement with the registry mandates a one-time fee 
structure
* require that the agreement with the registry cap the one-time fee at a 
level considered by IANA to be reasonable and non-descriminatory
* require that the agreement with the registry require a non-zero one time 
fee or an IANA-approved anti-hording mechanism if the fee is zero.

Do we need anything else from a technical perspective?

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 3 Nov 2003 16:08:43 +0100 (CET)

> Do we need anything else from a technical perspective?

I think I and Keith Moore commented on the application impact,
and to the extent that the current document doesn't state
the application impact very accurately.

Once that application impact is better known one could and should discuss 
the cost/benefit tradeoffs.

Since you missed the above rather major point, I wouldn't be surprised
if your summary misses other points that have been made.

   Erik

---

From: Hans Kruse <[email-masked]>
Date: Mon, 03 Nov 2003 13:19:58 -0500

My question regarding "need anything else" referred only to the registry 
requirements.  And I think we really need to delineate those requirements.

I do not appreciate your personal attack; reading either this specific 
message or the archive should make it clear that I did not "miss this major 
issue", I just do not agree with Keith and you that "outlawing" local 
addresses will accomplish anything to solve those issues.

Please explain to me how the job of applications gets any easier if the 
local addressing is done with a hijacked prefix....

---

From: Brian Haberman <[email-masked]>
Date: Wed, 05 Nov 2003 13:27:06 -0500

This is a reminder that the last call on the deprecation document
ends today.  In particular, the chairs would like to ensure that
the WG agrees on the actual deprecation text in Sections 4 & 6.
There has been few comments on this draft and it cannot proceed
unless the chairs can be sure that it has been thoroughly reviewed
and agreed upon.

If you have reviewed the document, have no issues with it, and agree
on its content, please let the chairs and/or the working group know.

Thanks,
Brian & Bob
IPv6 WG Chairs

Brian Haberman wrote:

> This is a IPv6 working group last call for comments on advancing the
> following document as an Proposed Standard:
> 
>     Title        : Deprecating Site Local Addresses
>     Author(s)    : C. Huitema, B. Carpenter
>     Filename    : draft-ietf-ipv6-deprecate-site-local-01.txt
>     Pages        : 10
>     Date        : 2003-10-13
> 
> Please send substantive comments to the ipv6 mailing list, and minor
> editorial comments to the authors.  This last call period will end on 5
> November 2003.
> 
> Brian Haberman / Bob Hinden
> IPv6 W.G. Chairs

---

From: Alain Durand <[email-masked]>
Date: Wed, 05 Nov 2003 10:47:33 -0800

> 4   Deprecation
 >  
 >   This document formally deprecates the IPv6 site-local unicast prefix
 >   defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The
 >   special behavior of this prefix MUST no longer be supported in new
 >   implementations.

I think this section is not ready yet. Couple comments:
 
1) This is not the IETF job to mandate what an implemention choose
    to support or not.

2) What constitute a "new implementation"?
    For example, we shipped IPv6 in Solaris 8. Same bits plus extra
    features in Solaris 9, more coming in newer relases, but fundamentally
    the same code fundation. Would Solaris 10, 11, 12, 13, 14....
    or what ever new name we come up with be considered as "new 
implemtations"?
    This is confusing...

3) What does section 4 exactly means with regard to default address 
selection RFC3484?
    Does this obsolete the rules about scope?

    - Alain.

---

From: Tim Chown <[email-masked]>
Date: Wed, 5 Nov 2003 19:45:51 +0000

> 1) This is not the IETF job to mandate what an implemention choose

But, for example, isn't that what the node requirements draft does?  Ok it
does not "mandate" but it uses wordage like "all IPv6 nodes can be
expected to implement the mandatory requirements listed in this document".

>    Does this obsolete the rules about scope?

Good point.  I assume RFC3484 will need a touch-up or clarification once 
this deprecation document goes past last call.

Tim

---

From: Hans Kruse <[email-masked]>
Date: Wed, 05 Nov 2003 14:15:18 -0500

I have no problems with the document content (and I did NOT try to read it 
for editorial nits...).

---

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Nov 2003 17:04:35 -0800

Brian,

In response to your last call, I'd like to comment on the following 
sections of the document:

Section 2.4 "Site is a Vague Concept"

This section does overstate the case.  The last paragraph itself is 
sufficient cause for concern, regarding the concept as it was 
envisioned.  There is nothing wrong with an administratively scoped 
boundary, and I would make that more clear.  What must be clear is what 
happens when you have more than one such beastie.

Section 4

I agree with Alain.  Any text that reads "MUST no longer be supported" 
is itself not supportable ;-)  The IETF cannot dictate this sort of 
behavior, and making claims that we can is not helpful.  I would simply 
state that the behavior is deprecated, and that new implementations 
needn't implement it.  Whether they choose to do so is a matter for them.

Realistically speaking I would be concerned if my routing vendor 
released a new piece of software that caused my existing network to stop 
routing.   Thus, the text, "However, router implementations SHOULD be 
configured to prevent routing of this prefix by default", is not quite 
right.  I understand this was not the intent, given what is said about 
existing deployments, but a router doesn't know from existing versus new 
deployments.  Rather, something like the following:

"New routing implementations should not support the functionality 
necessary to implement site-local scoping, and existing implementations 
should anticipate removing existing support at some point in the future."

Eliot
ps: you may use any of my words without listing me as an author ;-)

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Nov 2003 12:56:55 +0200 (EET)

> unless the chairs can be sure that it has been thoroughly reviewed

I do not believe the -01 version addresses the comments I made to the -00
version.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Nov 2003 16:58:30 +0100

Pekka, it's been a while, but my recollection is that we (the authors)
didn't agree and didn't see any support for your comments on the list.

I could be wrong.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Nov 2003 16:19:51 +0200 (EET)

> didn't agree and didn't see any support for your comments on the list.

There was no opposition, and there was support for at least referencing 
the SL-IMPACT work (or something else, giving a fuller description of SL 
problems).

On Thu, 6 Nov 2003, Christian Huitema wrote:
> Actually, the 01 draft includes two changes to address Pekka's feedback:
> add some explanatory text in section 2.2, address leak, and section 2.3,
> routing pain; and in section 5, qualify that the replacement of site
> local is only as secure if blocking rules are actually implemented at
> site boundaries. But it is clear that we want to keep the document short
> and concise, and thus chose to not widely expand the text in section 2
> and 5.

Yes, I noticed that some (most?) changes were incorporated, but at least 
the above (which I believe was important, and had some support) wasn't.

Of course the question then would be would the doc be normative or 
informative.  The former could block the document unless SL-IMPACT is 
published soon.  As there is already enough description of the issues, 
informational would probably be close to the mark..

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sun, 9 Nov 2003 23:36:17 +0900 (JST)

what have happened to anycast-analysis draft?  i believed that it is
	in IESG queue or RFC-editor queue, but it's not in
	http://www.rfc-editor.org/queue.html.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Nov 2003 19:37:26 +0100

Yes, correct, and SL-IMPACT must not become a blocking reference.

   Brian

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Nov 2003 21:32:23 +0100 (CET)

See

https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=draft-ietf-ipngwg-ipv6-anycast-analysis&search_rfcnumber=&search_area_acronym=&search_button=SEARCH

  Erik

---

From: [email-masked]
Date: Tue, 11 Nov 2003 21:48:59 +0900

>https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=draft-ietf-ipngwg-i…

	Bob (Hinden) sent me half dozen of AD comments made in August to me
	on Sunday.  why does AD comment have to be queued and delayed at
	WG chair?  they could send them directly to me, then i would have been
	able to update the draft before IETF58.

	anyways, sorry for the rant.  i will update the draft to reflect AD
	comments.

itojun