[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-hain-templin-ipv6-limitedrange-00.txt



Eliot,

I've just got around to reading the draft, and I'm puzzled by your reaction.

I think it's almost ready to ship. I thought I'd found one omission, then 
discovered that the point was in fact covered.

Maybe we are once again in trouble with the R-word. Perhaps if we
s/requirements/goals/ it would be better. Some details below:

Eliot Lear wrote:
> 
> Hello,
> 
> I've read over this draft, and I find it very confusing.  The title of
> the draft is "Limited Range Addressing Requirements".  However, as one
> goes through the document, there is both justification and requirements.
>   What time is spent on the justification for "limited range" addressing
> is using IPv4 and NOT IPv6 logic.  

I think Tony already said this, but network managers will continue
using IPv4 logic for many years. We don't have much choice, if we want
to persuade them to upgrade to IPv6.

> In part I presume this is due to
> somebody's notion of IPv6 registry policies.  

Really? We certainly worked hard to get the registries to a suitable
policy on /48. But their policies in general are fine, IMHO.

> I'm not sure.  But here
> are a few "for instances":
> 
> > There is a strong requirement for an easy-to-get, stable, private
> >    address space for use within a limited range. Reasons include:
> 
> > o  avoid costs associated with running a registration infrastructure
> 
> I've done this job for a very large company, as have many of you. I
> presume what you are talking about above is the management of network
> allocations.  That doesn't stop whether or not one uses site-locals XXX
> errr.. limited range addressing.  It does get easier with IPv6 given the
> fixed amount of space hosts have.  The vast majority of time is spent
> allocating and reallocating that which has already been assigned by the
> upstream authority.  Only rarely is there any interaction needed with an
> upstream for additional allocations.  It is a low frequency operation
> not to be optimized for.

True, but also it means that unless all PA prefixes in use *and* the
limited-range prefix have the same length (i.e. /48), subnet management
will be different for different prefixes. That is where I see the cost
argument.

> 
> > o  avoid exposing internal network plans to competitors
> 
> This is a procedural artifact of IPv4 that I have to believe can be
> gotten around.  In fact it probably could have been gotten around with
> IPv4 using existing auditing business relationships.

Although I think this "security by obscurity" belief is bogus, it is
very deeply held and I see no realistic prospect of getting rid of it.

> 
> Before I go through the remainder of the document on this list (and I
> believe I have substantial disagreement) I'd request the authors update
> the Terminology section to include at least the following definitions:
> 
> 1.  "limited range" -- in particular, what is the semantic difference
> between these and SLs?

IMHO, mainly that they mustn't be ambiguous. And we need to change the
name to avoid confusion.

> 2.  Redo "range" as its current definition doesn't help me much.

  domain of applicability of a given address prefix

> 3.  "validity" or "valid"

I see nothing specialized in the way it's used.

> 4.  "filter" or "filtering"

OK, a definition might help some readers.
 
  Brian

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

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------