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

From: Eliot Lear <[email-masked]>
Date: Mon, 04 Aug 2003 16:03:51 -0700

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.  In part I presume this is due to 
somebody's notion of IPv6 registry policies.  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.

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

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?
2.  Redo "range" as its current definition doesn't help me much.
3.  "validity" or "valid"
4.  "filter" or "filtering"

Thanks,

Eliot

--------------------------------------------------------------------
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 [email-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 4 Aug 2003 16:46:17 -0700

Eliot Lear wrote:
> is using IPv4 and NOT IPv6 logic.  

There are some historic 'lessons learned' included here, but the real issue
is meeting the expectations of the network managers who are currently using
IPv4 logic. That is not to say we don't want them to change, but we can't
assume they will even be willing to consider something that has a radically
different architecture.

> In part I presume this is due to 

You appear to assume that it is possible or desirable to expose the internal
use of previous allocations, to show that some derivative of the HD ratio
has been met to justify more space. It also appears you are looking at this
from the perspective of managing allocations internal to the local network.
The requirement was targeting the cost of maintaining an external central
registry, and specifically at the cost aversion of small organizations, not
large ones. 

> 1.  "limited range" -- in particular, what is the semantic difference 

From a routing perspective, nothing. SL meets the requirements for many
network managers (it just doesn't meet the puritanical expectations of the
IETF elite). From the identifier perspective, these are unambiguous. 

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

Send text.

> 3.  "validity" or "valid" 4.  "filter" or "filtering"
> 

Maybe I missed it, but it is not clear what you are looking for here. Other
than to argue that the requirements of some network managers don't meet your
goals for how they should run their networks, there doesn't seem to be any
suggested fix for the document. We will be happy to change the document, but
arguing someone else's requirement is not valid is not helpful.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Mon, 04 Aug 2003 17:15:42 -0700

> assume they will even be willing to consider something that has a radically

I think we differ on what "radical" is.  Besides, the architectural 
change is there in IPv6 today- you count networks not hosts.  This is 
merely a matter of taking advantage of it, right?

> has been met to justify more space.

No, I certainly don't think it's desirable.  Indeed what I'm saying is 
that auditors already need to know the financial state of affairs within 
a company, and they are already sworn to secrecy.  This same mechanism 
could be expanded to cover the total allocation required.  It's not that 
hard for a NOC to document, and in particular for IPv6 it really is a 
very simple counting exercise.  The justification is MUCH simpler for 
IPv6 than it is for IPv4.

  It also appears you are looking at this
> registry, and specifically at the cost aversion of small organizations, not

Well, even with the above wording I still don't really understand what 
registry you're talking about.  How does this differ from the in-addr 
function that a NOC (even a small one) must support?  I don't know what 
you mean by registry (internal or external).

> IETF elite). From the identifier perspective, these are unambiguous.

How so?  How about a diff in small words I can understand?  As it stands 
I feel as though we're going to relive history yet again by looking at 
an obfuscated rehash of what we just rejected.  No, I will not 
regurgitate the entire argument against SLs (y'all can thank me now).

Eliot

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 5 Aug 2003 17:05:53 -0700

Eliot Lear wrote:
> Tony Hain wrote:
> > There are some historic 'lessons learned' included here, 
> but the real 
> > issue is meeting the expectations of the network managers who are 
> > currently using IPv4 logic. That is not to say we don't 
> want them to 
> > change, but we can't assume they will even be willing to consider 
> > something that has a radically different architecture.
> 

From the operator perspective, the demand is for address space that is
architecturally set aside as private use, locally controlled. That did not
initially exist in IPv4, and history shows that people took whatever bit
patterns looked interesting.

> 
> > 
> > 
> > You appear to assume that it is possible or desirable to expose the 
> > internal use of previous allocations, to show that some 
> derivative of 
> > the HD ratio has been met to justify more space.
> 

But auditors are not running the RIR's. Are you inserting an explicit extra
cost into the system to have a 3rd party auditor certify the requests to the
RIR's?

> > from the perspective of managing allocations internal to the local 
> > network. The requirement was targeting the cost of maintaining an 
> > external central registry, and specifically at the cost aversion of 
> > small organizations, not large ones.
> 
> > network managers (it just doesn't meet the puritanical 
> expectations of 
> > the IETF elite). From the identifier perspective, these are 
> > unambiguous.
> 

That is because everyone has a different perspective on what their Yes vote
meant while the No votes were very clear about why we need something to meet
the operational requirements. 

As routing locators, it is not the IETF's role to tell network managers that
they can't limit the domain of applicability where an address is valid for
use. 

As an identifier, the IETF is in a position to say there will be no
intentional duplication to cause ambiguity, which would create a domain of
applicability for the identifier.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Aug 2003 17:29:39 -0700

Tony,

> patterns looked interesting.

I could see an argument for both enterprises and service providers, but 
the argument is different.  In the case of enterprises, they wanted the 
space because they couldn't get enough out of the registries, as we were 
running out of space with v4.  They also wanted the space because 
renumbering is a painful operation.  I would agree that is still a 
fundamental problem that MUST be addressed.  This is why I think we 
should work on Fred's draft.

With service providers, the argument is one of proxy for enterprises, 
where they were unable to get space for them, and needed a solution. 
That problem should be all but gone.

> cost into the system to have a 3rd party auditor certify the requests to the

Of course not.  But look, we've just taken a left turn in the 
discussion.  Now what you're saying is that we don't have a scalable 
process to give every host a globally routable address.  We need that no 
matter the outcome of this discussion!

Eliot

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 6 Aug 2003 11:04:48 +0200

> patterns looked interesting.

You must talk with different operators than the ones I talk with.

I have heard operators wanting address space for the following:

  - Private networks which are never routed to the Internet
    (management and various things like GPRS things), but
    possibly routed to peers, i.e. there might be the need
    for local routing

This can be done by using real addresses which are never routed to the 
Internet. This is something which is possible to do in IPv6 but not 
IPv4 due to RIR policies. So, today, the ISP's use RFC 1918 addresses, 
but of course peering then end up being a problem. Because of this, we 
see telcos using 11/8 and such IPv4 space for gprs.

In IPv6 world, real addresses can and should be used.

  - Private networks which they nat customers behind so the
    customers can not so easy set up their own servers

This is a packet filter/security issue and not a NAT issue. The 
selection of NAT is a bad thing, and this is exactly what we should 
prohibit in IPv6 world. Yes, the ISP can still sell filtered access of 
various kinds and possibly a large portion of the users out there want 
it. But, it should not be part of the architecture.

  - Private networks for certain services which is located
    close to the customers so the same IP address is reused
    at every pop

The ISP can in IPv6 world take a portion of their (real) address space 
and do the same thing. That ISP's today use RFC 1918 addresses means 
the RFC 1918 addresses are (for the customer) not used as intended, but 
as real addresses. In IPv6 world this is not needed.

  - Tons of addresses so they can redesign their internal
    network a lot without risking renumbering

With IPv6 they get many many more addresses than before, so they don't 
have to allocate /29 here and there in IPv4 for small networks which 
should only have a few hosts. They can have the same netmask all over 
the place. And still limit the size of their broadcast domains.

     paf

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 6 Aug 2003 12:10:17 +0200

I have now checked the document in the subject line _again_, and I 
think the basic problem is that (a) I don't agree with all of the 
problems listed being problems and (b) I definitely see the solution to 
many of these (as you see below in my mail earlier today) being to 
"just" use real IP addresses.

For example, that administration and registration of addresses is a 
pain and should be easier (not needed even) is a RIR issue, and should 
definitely not be an argument for using scoped addresses.

Now I am going back to Application Layer issues for a while.

    paf

On onsdag, aug 6, 2003, at 11:04 Europe/Stockholm, Patrik Fältström 
wrote:

> the RFC 1918 addresses are (for the customer) not used as intended, 
> but as real addresses. In IPv6 world this is not needed.
>

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 10:14:05 -0700

Patrik Fältström wrote:
> > architecturally set aside as private use, locally 
> controlled. That did 
> > not initially exist in IPv4, and history shows that people took 
> > whatever bit
> IPv4 due to RIR policies. 

Not unless the site is willing to pay an ISP for address space, then
probably pay extra to make sure it does not get routed as part of the ISP
aggregate.

> So, today, the ISP's use RFC 1918 
> addresses, 

Local address space MAY be used by ISPs, but the primary target for local
use space is the edge network. I agree that when ISPs use unrouted space,
results may not be deterministic. 

> In IPv6 world, real addresses can and should be used.

Real or imaginary are perspectives of the onlooker. I suspect you intended
'globally routed'. 

> it. But, it should not be part of the architecture.

I absolutely agree, and have been working on documenting similar
requirements for address space that is known to not be globally routed. 

> as real addresses. In IPv6 world this is not needed.

Duplication of addresses is not 'needed', but may be perceived as an
operational simplifier (ie: the dhcp servers in every pop are 192.168.255.1,
ACL configs at every pop are the same ...). This is not arguing that we need
to keep that, just pointing out that there are operational costs to changing
the model. One thing that is required is that an ISP have a means to provide
private networks to their customers. The address space for these can't be
taken out of the same aggregate that is being announced to peers, else the
network is not really private. 

> the place. And still limit the size of their broadcast domains.

Nice in theory, but when route filtering practice hits the fan, there will
be allocations within networks that don't seem to make any sense from the
outside. There are many more bits for aggregation, so having different
lengths and exposing the topology details should not be as frequent as in
IPv4, but there are times that the aggregate policy does not match the
longer prefix, so those will still show up. The real problem with
restricting access happens when the aggregate policy is more open than the
longer prefix wants to be.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 6 Aug 2003 10:39:10 -0700

Patrik Fältström wrote:
> problems listed being problems 

The point is the guy on the street deploying a network sees these as
problems. Yes the IETF members can usually figure out work-arounds, but that
is done in the absense of knowledge about the cost constraints of the guy
deploying the network. Unless the IETF acknowledges the problems as
problems, then documents cost-effective work-arounds, the guy on the street
will figure out his own solutions. 

That said, the document needs to reach WG consensus, so if there are issues,
send text.

> and (b) I definitely see the 
> solution to 

Aggregatable PI space would solve many, if not most of these issues. The
lack of aggregation in PI is why the draft says local use and a PI with some
minimal aggregation should be worked on in parallel. 

> definitely not be an argument for using scoped addresses.

The RIR's are not the bad guys here, they are doing nothing wrong. It costs
money to run a registry, and those costs need to be recovered. At the same
time, many edge network managers will refuse to be locked into a provider,
but can't see any value in paying an RIR to maintain a database.
Particularly when there is so much space that picking random numbers is
unlikely to create a problem for quite awhile. 

Tony 

> >> From the operator perspective, the demand is for address 
> space that 
> >> is architecturally set aside as private use, locally 
> controlled. That 
> >> did not initially exist in IPv4, and history shows that 
> people took 
> >> whatever bit

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 7 Aug 2003 09:34:56 +0200

> Real or imaginary are perspectives of the onlooker. I suspect you 

Yes, sorry. As I only work in this space (below transport) with 
scuba-gear on, I often make mistakes when selecting crisp wording.

    paf

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Aug 2003 11:28:30 +0200

And the fact is that enterprise network managers are
very happy to have a class of addresses that cannot be
globally routed and are filtered by default as bogons by all ISPs.
So they just love RFC 1918 addresses for that, and hate them
for their ambiguity (since that creates a mess when they
have to be routed anyway, e.g. on VPNs). The main point of this draft, 
as far as I'm concerned, is to convey this requirement, which isn't met
either by PA prefixes or the old SL prefix.

   Brian

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Aug 2003 15:41:52 +0200

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:

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

> 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

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.

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

> 1.  "limited range" -- in particular, what is the semantic difference

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