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

[Keith Moore <moore@cs.utk.edu>]

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------