Subject: RE: Geoff Huston's draft and the intended use of the hinden/templin address space

From: "Michel Py" <[email-masked]>
Date: Sun, 10 Aug 2003 13:24:00 -0700

Eliot,

> Eliot Lear wrote:
> Subject: Geoff Huston's draft and the intended use of
> the hinden/templin address space
> If the sole purpose of these addresses is for layer 3
> connectivity as envisioned for LOCAL USE, then I would
> agree with Nir Arad that we do not have a problem.

Same here, however I do not think we can talk in terms of purpose. The
peril of these addresses is precisely that they will be used to ways
contrary to their purpose, which needs to be taken into account.

> If on the other hand, as Geoff states in his draft, and some
> people seem to be implying, that these addresses could be used
> as some sort of end point identifier outside of the routing
> system, then we do have a problem.

Note that as author of a two-space locator/identifier protocol I do not
share this point of view. There is a need for a private address prefix
that is completely separate from the prefix used for end-point
identifiers. Among other things, I fear that using private addresses as
end-point identifiers for global traffic will lead directly to NAT.

Conceptually, the endpoint identifier is like a PI address, which it
targets to replace. The only reason for the separation between endpoint
identifiers and locators is that it enables a reduction in routing table
size, _not_ because it wants to blend the identifier with the private
address. These are separate animals.

Michel.

--------------------------------------------------------------------
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: "Nir Arad" <[email-masked]>
Date: Mon, 11 Aug 2003 10:20:02 +0200

> contrary to their purpose, which needs to be taken into account.

I would like to point out again, that as per my suggestion, nodes MUST NOT send, receive or forward traffic in which the
source and destination addresses are not of the same scope.
Thus, it will not be possible to use NAT on scoped addresses:
Even if hosts would diverse from this specification and send packets from local to global scopes, they can not rely on
routers inside the organization to forward it to the NAT at the edge.
Thus hosts will naturally turn to global addresses for external communications.

As for internal communications (here's another flame bait):
I propose to prefer global addresses too.
Only those "special, internal applications" that should maintain very long term connections at the transport layer
should be a little complicated by allowing the user to prefer local addresses, thus addressing the debated stability
issue.
Hosts will be forced down to local addressing only if the destination has only a local scope address (e.g. an internal
printer).

Regards,

-- Nir Arad

---

From: Andrew White <[email-masked]>
Date: Mon, 11 Aug 2003 18:02:50 +1000

Nir Arad wrote:

> Only those "special, internal applications" that should maintain very
> long term connections at the transport layer should be a little
> complicated by allowing the user to prefer local addresses, thus
> addressing the debated stability issue.
> Hosts will be forced down to local addressing only if the destination
> has only a local scope address (e.g. an internal printer).

Define 'special, internal applications'?
- Is my NFS mount a special, internal application?
- What about my game session?
- My ssh session to a server?

Define 'very long term'?

From an IPv6 ISP I'm probably safe up to a week.  However, if my global
connection is from a hot spot or 6to4 address I have very little guarantee
that the prefix will persist more than a few hours.  In contrast, my local
address prefix is guaranteed to last as long as the router or network does.

Applications that don't do forwarding of IP addresses simply need an address
that they can route to.  The local address is as good as any, and has the
nice side effect of being more robust against failure (or deprecation)
external to the site.

Applications that do forward IP addresses can't a-priori trust any address,
since they can't know where the filters are (if any).  Safe strategies
include:
  - manual configuration
  - send DNS names and let the target choose
  - send all available options and let the target choose (this isn't a very
good option)
  - additional information

I'll also note that no deployment is forced to use local addresses - if
someone or something doesn't configure them then they won't exist.

There is a solution that will cause all these considerations to be obsolete
- strictly enforce one (and only one) address per node.  And ban filters
while you're at it.  Any takers?

Side point: a policy which allows for local addresses but auto-deprecates
them when an external address becomes available causes local addresses to
lose one advantage - the local address is now subject to failure because of
site-external events.

> I would like to point out again, that as per my suggestion, nodes MUST
> NOT send, receive or forward traffic in which the source and destination
> addresses are not of the same scope.

I think this is unnecessarily stringent.  Certainly nodes should prefer not
to send packets with non-matching 'scopes' (see "default address
selection"), but I don't see it as an error condition to do so.

-- 
Andrew White

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 14 Aug 2003 09:56:15 -0700

Andrew White wrote:
> ...
> > NOT send, receive or forward traffic in which the source and 
> > destination addresses are not of the same scope.
> 
> I think this is unnecessarily stringent.  Certainly nodes 
> should prefer not to send packets with non-matching 'scopes' 
> (see "default address selection"), but I don't see it as an 
> error condition to do so.

In the past I agreed with you, but lately I have been more convinced that it
is a logical error. There is nothing that will prevent someone from doing
this if local policy says to allow it, but I think the default policy should
be that local/global mismatches are disallowed. This would make it simpler
to set up a condition where the policy is 'file mount is only bound to
local', node X only has a global address, therefore X is not allowed to
export a file system. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Aug 2003 17:00:40 -0400

>  I think the default policy should
> be that local/global mismatches are disallowed. This would make it
> simpler to set up a condition where the policy is 'file mount is only
> bound to local', node X only has a global address, therefore X is not
> allowed to export a file system. 

The default policy should be that everyone should use the same address.
It is not appropriate to tie access control to addresses.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------