Subject: comments on draft-hain-templin-ipv6-localcomm-03.txt

From: Keith Moore <[email-masked]>
Date: Wed, 12 Nov 2003 15:00:04 -0500

These are comments on the document rather than on Tony's presentation 
yesterday

I think the notion of "local-use" address conflates several different 
things that are better treated as separate subjects.  Even if one 
accepts all of these as valid problems (which I don't), it's not clear 
that they should all share the same solution.

If you want to argue that (managed or self-organizing) networks that 
are not connected to the public Internet need to be able to get address 
blocks easily, which allow them to connect with other networks by 
private agreement, I agree entirely.

If you want to argue that networks need stable addresses for internal 
use that allow local applications to survive renumbering and/or moving 
the attachment to the public internet, I agree with this also.

If you want to argue that nomadic networks (whether "personal area 
networks" or on a larger scale) need stable address blocks, which can 
be used to communicate within the network, and which allow them to be 
connected to and/or merged with other nomadic networks, and which also 
allow them to intermittently connect to stable networks with or without 
public internet connectivity, I agree entirely.

(I prefer "nomadic networks"  to "active sites", since "active 
networking" has been used to mean something else.  And I think the 
notion of "site" is semantically loaded in a way that is not productive 
to this discussion - in particular, the scope of a network does not 
necessarily coincide with a single administrative entity or boundary.  
Also we need to consider both auto-configured/ad-hoc networks and 
managed networks, which seems to be inconsistent with the notion of  
"site".)

However if you want to argue that the boundary of a network using a 
particular kind of prefix is something that hosts or applications 
should inherently or automatically recognize as a boundary for 
trustworthiness or as a limit to the range of the services they 
provide, I strongly disagree.  The host or app can detect that a 
potential peer is using a different network prefix, but that says 
nothing about "who it is" or even "where it is".  It is not appropriate 
for the host or app to assume anything about the relative 
trustworthiness of either "local" or "nonlocal" peers.  This certainly 
isn't something we should support as part of the addressing 
architecture.    Long experience indicates that addresses are poor 
indicators of trustworthiness.

So it is NOT the job of an addressing scheme to protect "private" 
assets from exposure to the public Internet - because the notion of 
"private" is arbitrary and the policy governing external access can and 
in many cases should not be based on the address prefixes in use.  A 
nomadic host may move from one address to another, from a local address 
(e.g. home network) to a global address (public dialup or mobile access 
network) and then to another local address on a different network that 
still connects with the first one.  The fact that the host moves should 
not inherently affect its ability to access services, and it's not 
desirable for the architecture to support an assumption that this is 
even desirable.

If you want to argue that network administrators will filter traffic to 
sets of hosts, I agree entirely.  However they should realize that this 
technique is not sufficient to ensure the security of those hosts from 
attack - as experience indicates.  Filtering can be useful as part of a 
defense-in-depth but should not be considered a substitute for 
authentication.

If you want to argue that network administrators will prefer to filter 
traffic on the basis of network prefix rather than listing specific 
hosts, I agree entirely.  However they should be aware that this 
approach is somewhat inflexible in several ways, and thus of limited 
applicability.

If you want to argue that it therefore makes sense to encode policy 
into addresses, and to expect hosts and applications to use the "right" 
source or destination address for a host in order to negotiate a path 
through the network to the destination that is consistent with policy, 
I strongly disagree.  This is a far worse overloading of the IP address 
than say, using the IP address as a host identifier.  In general, hosts 
and apps cannot be expected to be aware of the policy governing use of 
particular IP address prefixes in particular environments.  Nor is it 
reasonable to expect multi-node applications to implement policy-based 
routing through such networks.  Nor is it even reasonable to expect 
address selection algorithms to cope with such apparently arbitrary 
distinctions.

Can a network, under some conditions, use filtering of address prefixes 
as a crude policy mechanism for enforcement of crude policies without 
doing much harm?  Probably, but that's a far cry from claiming that 
it's generally desirable to encode policies into IPv6 addresses.  Nor 
is the desire to use this as a policy mechanism justification for 
harming the flexibility of the IPv6 network to support diverse types of 
applications.

Similarly the notion that a designated address prefix provides a "hint" 
to applications regarding filtering is a dubious one - for a variety of 
reasons.  It conflicts with the desire to be able to interconnect with 
other private networks.  It assumes that the same policy applies to all 
applications on a network when it's much more realistic for that policy 
to vary from one host or application to another.  Even if the app has a 
clue that its traffic might be filtered, this really is not useful as a 
policy indication - should this be taken as an indication that the app 
cannot communicate with that host at all, or instead as an indication 
that the app must route its requests through an intermediary?  Even if 
it did not create undesirable conflicts over address assignment, the 
idea that what is essentially a single bit of policy indication is 
useful to all hosts and all apps on a network is ridiculous - certainly 
not something that we should provide for in the architecture.

Regarding stability of addresses - a certain amount of stability is 
necessary for long-running applications, though perhaps indefinite 
stability is too much to ask.  Any network will from time to time be 
re-organized, hardware will be replaced, etc.  An app  or host that 
relies on infinite stability - even in the presence of GUPIs or PUPIs - 
is probably being unrealistic.  There is certainly a need to provide 
stability during such transitions - in order that they can be handled 
gracefully - but that's not the same thing as expecting addresses to 
last forever.  Regarding the example of the alarm system, is it really 
reasonable to expect an alarm system to communicate when external 
monitors without being able to tolerate changes to the external 
monitors' addresses?

Another problem with encoding policy into IP addresses is that it makes 
it considerably more difficult to handle interconnections between 
various types of networks (self-configuring vs. managed, core-connected 
vs. private) and the transitions between some of those states that 
occur as the result of new connections or disconnections.  Coping with 
transitions between PA, PI, and 6to4 addresses is already difficult 
enough; overloading those addresses with policy makes it infeasible.

So - yes, we need addresses that can be easily allocated for local use 
(and perhaps for other purposes also), but they should not carry with 
them any assumptions about the degree of locality or proximity, 
trustworthiness, filtering, or policy.

Keith

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

---

From: Andrew White <[email-masked]>
Date: Thu, 13 Nov 2003 14:24:35 +1100

I think we're missing the point.

There is a perceived need by "many" operators for an address space that can
be used for 'local' use, where 'local' is 'not part of the global
internet'.  We can argue until the cows come home whether any given possible
use for such a space is good or bad, but the fact remains that there is
demand for such a space and that it is thus better to allow for it's
allocation in a managed manner rather than have it snatched from whatever
ad-hoc place the network manager decides.

Fundamentally, there are 2 requirements:

- Free (both financially and administratively)
- Approximately unique

Operationally, we impose an additional requirement:

- Using such space should not add to the size of the global routing tables.

An unadministered PI scheme that generated unique prefixes would satisfy the
first 2 requirements.  However, allowing such addresses to be globally
routeable has two drawbacks:
- affects global routing tables, possibly badly
- raises 'approximately unique' requirement to 'unique'

Introducing compulsory filtering outside whatever administrative boundaries
these addresses have removes these two drawbacks.  These addresses become
unusable for global communication, but then they are not intended for global
communication.

Assuming the 'unique enough' mechanism is unique enough, the only difference
between a 'local' address and a 'global' address which is administratively
filtered is that EVERYBODY is filtering the local address, so if it slips
past one filter someone else will probably throw it away.

This is NOT a security argument.  Local addresses are neither more nor less
secure than any other filtered address.  Rather, local addresses are
intended to provide an easily accessible PI space for people wanting easily
accessible PI space, without risking address space conflicts with global
addresses.

So what changes are needed:

- To applications?  None.  A local address may be treated as a global
address, and will function identically to any filtered global address.  The
only difference is that the local address prefix provides a strong hint that
the address WILL be filtered, thus increasing the ability of an application
to make address selection choices if it so wishes.

- To routers and infrastructure?  Many of these devices SHOULD have filters
configured to discard local addresses.  Those that do not may suffer some
increased traffic.

Nothing breaks that wont break already.  The cost to those that don't want
to use these addresses is minimal.  And some people gain functionality they
particularly want.  Where is the problem?

I'll offer one comment on the Hinden/Haberman draft.  Although I'm generally
in favour of it, the draft completely partitions the space into that which
is registered and that which is allocated using the provided random
algorithm.  No space is left for alternative mechanisms, such as MAC based
allocation presented in draft-white-auto-subnet-alloc or
draft-hinden-ipv6-global-site-local.

-- 
Andrew White

---

From: Keith Moore <[email-masked]>
Date: Thu, 13 Nov 2003 12:15:43 -0500

> internet'.

We need to dispel that perception.

Operators are free to filter traffic going to and from their networks 
as they see fit.  What's not reasonable is for the architecture to tie 
policy, or any expectation of filtering, to the kind of address prefix 
in use.

- it over-constrains use of the address space for more legitimate 
purposes
- it conflicts with the desirability of being able to communicate 
between networks using non-global addresses
- the notion of 'local' is too vague and too subject to variation
- any attempt to encode policy in address bits is going to be too 
inflexible to be applied to all apps and/or all hosts on a network - 
this is true even if you restrict it to "appliance" hosts
- the idea that 'local' hosts are somehow trustworthy is a very dubious 
one
- it imposes an onerous burden on apps that are expected to work across 
"local prefix" boundaries

I agree that it's desirable to have a way for the network to 
communicate policy to hosts and apps, but this isn't a suitable 
mechanism for doing so.

(If we want to overload addresses, there are lots of other ways to 
overload them that would be useful.  e.g. why not encode TOS in address 
bits?  after all, existing routing policy mechanisms would make it easy 
to implement.)

> - Free (both financially and administratively)
or within epsilon of free.

> - Using such space should not add to the size of the global routing 

no problem with any of the above - just with the idea that these are 
"local" as opposed to "non-routable in the public network".  and the 
current proposal satisfies the above criteria quite nicely.

>  allowing such addresses to be globally
> these addresses have removes these two drawbacks.

That's the wrong way to define it.  People need to be able to route 
between private networks even if some or all of those networks are not 
connected to the public internet.  So we need to be able to route 
between networks that use nonglobal addresses.

> filtered is that EVERYBODY is filtering the local address,

only at the boundaries between their network and the public internet.  
They're free to filter or not filter such addresses at private 
interconnections between their networks and other networks.  They're 
free to provide transit for nonglobal addresses also.

> to make address selection choices if it so wishes.

False.   Apps can't expect networks to filter all traffic using 
nonglobal addresses at their boundaries, because there are too many 
reasons why networks using nonglobal addresses might need to exchange 
traffic over private links.  Apps can't even tell whether a potential 
peer that uses a global address is unreachable, since some networks 
using nonglobal addresses will still need to exchange traffic over 
private links with other networks that use global addresses.

> configured to discard local addresses.

Except at the boundaries between their networks and the public 
internet, this is entirely a matter of local network policy.

> Nothing breaks that wont break already.

False.  People can certainly configure their networks now in ways that 
will break things, and of course this won't change.  But what you are 
proposing is to _encourage_ people to configure their networks in ways 
that will break things, while at the same time making their networks 
less flexible.  (e.g. by requiring any network that wants to connect 
with another network to acquire global addresses whether or not it 
connects to the public network).

>  The cost to those that don't want
> to use these addresses is minimal.

False.  If we were to adopt what you propose, everyone would be 
burdened with apps that tried to cope with a hodgepodge of addresses 
with varying and uncertain reachability.  This would increase the cost 
for everyone.

>  And some people gain functionality they

See above.  Just because people want a certain kind of functionality 
doesn't mean we should implement in in the way that seems obvious to 
people who haven't considered all of the implications.

> draft-hinden-ipv6-global-site-local.

Good point.  Offhand I'd think that a MAC could be used as an 
alternative way to generate a "random" number - run it through MD5 or 
some such.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Sun, 16 Nov 2003 23:17:09 +0100

| An unadministered PI scheme that generated unique prefixes would
satisfy the
| first 2 requirements.  However, allowing such addresses to be globally
| routeable has two drawbacks:
| - affects global routing tables, possibly badly
| - raises 'approximately unique' requirement to 'unique'

<stupid-question>
The global-routing-table-size argument crops up often. Could someone
produce a link to a document which explains exactly what the problem
is (I know what the problem is believed to be) and why it is considered
a biggie.<stupid-question>

<shocking-ingorance>
I have heard figures to the effect that current usage of v4 PI
translated into v6 PI would require on the order of 1G memory in
bgp routers. I just can't figure out why 1G memory is considered
a lot in this game - my graphics card will probably have next to
that much in a couple of years and I haven't bought a pc with
less memory for a couple of years now...
</shocking-ignorance>