Subject: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt

From: Alex Zinin <[email-masked]>
Date: Mon, 11 Oct 2004 16:17:55 -0700

skill-specific: Rohit (generic routing in this case)
round-robin: Radia

This one is on the IESG telechat for this Thursday. Reviews by end of Wed would
be appreciated. Luckily this is a short read.

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-06.txt

> Abstract
> 
>    This document defines an IPv6 unicast address format that is globally
>    unique and is intended for local communications, usually inside of a
>    site.  They are not expected to be routable on the global Internet.

-- 
Alex
http://www.psg.com/~zinin

---

From: Radia Perlman <[email-masked]>
Date: Mon, 11 Oct 2004 19:52:54 -0700

Well, this may or may not be a good idea, but the document does not explain
the purpose of this. Perhaps it does, obliquely in the "characteristics" 
part of the
intro. Why is this better than just a single prefix meaning "site-local" 
that routers
on the boundary refuse to forward to/from?

The only two reasons I can imagine are that "in case it accidentally 
gets routed off
the site, it won't conflict with other addresses", and "in case you 
merge two sites,
you won't have to renumber".

However, if border routers are "accidentally" forwarding these things,
I'd think a whole bunch
of assumptions are going wrong, and it's not clear how many problems 
would be
solved by making sure these addresses won't conflict with an address 
outside the site.

And the other issue...of not needing to renumber. If two sites wind up 
adjacent, is
the intention to merge them? Would both prefixes then be considered 
"site-local"
and equivalent (like on a LAN, where IPv6 allows multiple prefixes). Or 
is it
a way of ensuring that two sites don't accidentally get merged even if 
the routers on
the boundary are confused and don't realize they're on the boundary?

Anyway, I'd like to see a much stronger intro about why this is needed, 
what behavior
they'd like to see if two "sites" are connected together, and what 
problems this
solves as opposed to a single site-local prefix.

Radia

---

From: Alex Zinin <[email-masked]>
Date: Wed, 13 Oct 2004 18:45:28 -0700

Radia,

  Thanks a lot for the review.

  Regarding the questions on why this is needed and why no a single "site-local"
  prefix: there was a long discussion in the IPv6 WG last year (I think), that
  resulted in getting rid of the site-local addresses. There were a number of
  reasons for this, too much for one e-mail (you could still go to the IPv6
  WG archives). Bottom line is--the functionality provided by site-locals
  was important, but the details added complexity at different levels. This
  approach offers similar functionality with lesser problems.

  I agree that the desired behavior for site merger should be clarified.
  I will add this to my discuss on this doc.

---

From: Radia Perlman <[email-masked]>
Date: Wed, 13 Oct 2004 22:34:55 -0700

I'd recommend not only explaining the behavior when merging sites, but
also a discussion of what the problems with a single prefix meaning 
"site local"
would be, and why this does not have the same problems.
Perhaps people would be reluctant to do this because
they feel it might be political, and any attempt to explain will ruffle 
feathers,
but the only way to understand any of this stuff is to be brave enough to
capture the contentious issues and explain both sides and the reason for
having chosen the particular direction. If the reason not to put it in is
"it would take too long to explain it", that is really not a valid 
excuse. (I'm
not complaining about your not explaining it in the email...I'm just 
saying that
in a document there is room to explain it...how complicated could the
issues be? And posterity will thank them for the explanation even if 
posterity
might disagree with the conclusion.)

Radia

---

From: Alex Zinin <[email-masked]>
Date: Thu, 14 Oct 2004 08:53:12 -0700

Radia,

  I just realized we have reasons for deprecation of site locals documented.
  RFC 3879 is the one to look at.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 15 Oct 2004 11:39:39 -0400

Since I'm having to deal with some IPv6 stuff this week, I read
this draft.

While the IANA considerations section sets aside fc00/8 as "centrally
assigned", it doesn't instruct IANA to manage the allocations for
this nor set allocation policies.

Was this intentional?

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 15 Oct 2004 11:54:45 -0400

> Since I'm having to deal with some IPv6 stuff this week, I read

I also just noticed that there is at least one random spot where
RFC 2119 capitalization probably should be done.  Specifically,
section 4.0 with regards to BGP.

An audit of such capitalization prior to publication would be handy.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Fri, 22 Oct 2004 17:02:15 -0700

Jeff-

 Thanks for looking at this. This concern was raised in the IESG.
 The answer was that the instructions would be published as a separate
 document--could be in draft-ietf-ipv6-ula-central-00.txt.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 22 Oct 2004 17:03:15 -0700

Jeff-

 See my reply to Bob... they should _really_ make it clear what's intended as
 operational guidelines, and what's expected to be changes in the router code.