Subject: RE: Naming and site-local addresses

From: "Michel Py" <[email-masked]>
Date: Sun, 10 Nov 2002 17:15:16 -0800

Harald,

Harald Tveit Alvestrand
> This seems to lead me to one of two conclusions:
> - Address lookup is significantly more complex in the
> presence of site-local than if only global-scoped
> addresses are used
> - I missed something.

I think you missed the fact the dual-headed DNS you mentioned is in use
in many organizations even the ones that have only global-scoped
addresses. One of the main reasons is that networks administrators don't
want their DNS servers to resolve the entire network if the request
comes from the outside.

In other words, if foo.example.com is a secure host, it makes a lot of
sense to configure the DNS servers to resolve it if the request comes
from within the administrative boundaries of the site, and *not* resolve
it if the request comes from the outside.

Therefore, the complexity of administering the dual-headed DNS is not a
by-product of the use of site locals, but a desire of the administrator
to limit lookups.

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: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 11 Nov 2002 08:00:13 +0100

> it if the request comes from the outside.

That is well known.

It's also a pain to configure, and the names leak all over the place (check 
out the Received: headers of this message - there should be at least one 
leaked "internal" name in it, with a corresponding 192.168.x.x IP address).

I run two different DNS servers on a 7-machine home LAN in order to support 
this configuration; I can't get redundant DNS servers for the local clients 
because I don't have a third machine (and don't want to configure Bind 9 
with zone support - too much work to learn).

> by-product of the use of site locals, but a desire of the administrator

My question to you is whether:

- the use of site-local FORCES you to use split DNS, even if you otherwise 
don't need to

- the use of site-local and split-DNS FORCES you to let the boundaries of 
the site follow the boundaries of your security perimeter, or suffer the 
N*2 problem of having to manage four categories of names rather than two

(btw, IMNSHO, the security argument for split DNS is security through 
obscurity - it only protects you against the stupid bad guys....)

                  Harald

---

From: Tim Chown <[email-masked]>
Date: Mon, 11 Nov 2002 08:32:12 +0000

> N*2 problem of having to manage four categories of names rather than two

Well, it's not uncommon that hosts in DNS domains do not always fall into 
what would be one site, thus hosts pointed to by aaa.foo.com, bbb.foo.com 
and ccc.foo.com can be in entirely different administrative and physical 
sites.  This would cause some site-local headaches.

I agree with Keith that the logical conclusion is that whenever a site-local
and global address are returned the only non-ambiguous decision to take is
to prefer the global address.  But that means we lose the nice property of
prefering site-locals intra-site to help maintain long-standing connections
(e.g. NFS) through external renumbering or connectivity events that alter 
global prefixes seen within the site.   

It seems the only way around that is to either use a special unique 
"site-local global" prefix internally (plucked from some method as yet 
undefined, Keith's ideas to date there are "woolly" at best :) or to use a 
parallel/split DNS naming structure internally (be it foo.site or otherwise, 
indeed in my own NATed v4 home network I use .home in the scope of my home 
network for that purpose on Net10, not pretty but it works), or to use only
site-local literals.  Are there other solutions?

There seems no easy answer either way, but the dangers of site-local addresses
leaking or causing problems (the mobility question seems particularly nasty)
means the sane solution surely has to be preference for globals?

> obscurity - it only protects you against the stupid bad guys....)

Little different to NAT :)

Tim

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Nov 2002 17:25:31 -0500

> site-local literals.  Are there other solutions?

I actually think that all applications that expect to keep associations
around more than some well-known (and explicitly chosen) lifetime need 
to have mechanisms for surviving renumbering.   And unless/until 
we introduce renumbering support into TCP, UDP, and SCTP, this means
providing that support in layer 7.

I also think there needs to be a minimum overlap time during renumbering
(during which both prefixes are valid), which is greater than or equal 
to the max reliable association lifetime above.  That way, if an application 
gets a valid prefix when it starts, that prefix will remain valid for at 
least the max reliable association lifetime.

In other words, I'd rather make a distinction between applications with
long associations and applications which don't need long associations
than between site-local applications and applications that might need
to cross site boundaries.  In practice I don't think there are many
inherently site-local applications.

Keith

p.s. offhand I suggest that that lifetime should be 10 days.

---

From: Mark Smith <[email-masked]>
Date: 12 Nov 2002 11:38:00 +1100

Hi All,

On Tue, 2002-11-12 at 09:25, Keith Moore wrote:
<snip> 
> providing that support in layer 7.

Isn't this really the End-to-End argument, which I think pretty much
summarises to "if you want something done properly, you've got to do it
yourself".

We are focusing on renumbering being an event that will disrupt TCP
sessions, which obviously it will. But what about the interface failing 
that the operating system chose to use as the local end-point IP address
for the TCP session ?

Renumbering is a planned, managed and controlled event, interface
failures obviously isn't.

If the operating system makes an unfortunate choice of source IP
address, by using an interface that is going to fail in the near future,
the application's TCP sessions will fail. If that is unacceptable to the
application, the application has the most interest in implementing
mechanisms to reduce or avoid the impact of that failure.
 
Are we trying to solve a problem at the network layer, which impacts the
transport layer, which really is best and most appropriately solved at
the application layer ?

In the context of the End-to-End argument, could TCP/SCTP be seen to be
a performance enhancement for the application, rather than trying to
provide "perfect" reliability ?

Should it really be "dumb network, smart hosts, wise applications" ? 

Regards,
Mark.

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Nov 2002 20:07:40 -0500

> summarises to "if you want something done properly, you've got to do it

There is a similarity between my argument about association liftimes
and the end-to-end argument, but I think you're mis-characterizing
both of those arguments :)

I see the end-to-end argument as being about separation of function.
Let the network do what it can do best, but don't try to make it do things
(like provide reliable and in-order delivery of messages between hosts) 
that it can never do well.

A similar but less-often-stated argument can be applied to hosts: let hosts 
do what they can do well (like ordering messages and recovering from dropped 
messages), but don't try to make them do things (like routing) that they can 
never do well.  

It doesn't scale to expect the network to keep track of every connection
between hosts.  Neither does it scale to expect all hosts to maintain
enough information to let them do routing. 

My argument about association lifetimes is also a separation-of-function
argument.  The idea here is that it's perfectly reasonable to expect
the network to maintain addresses for some well-chosen period of time;
applications that don't need addresses to be stable for longer than
that shouldn't have to worry about renumbering.  On the other hand
it's clearly unreasonable to expect the network to make addresses
stable indefinitely - first because it's too much overhead and second
because there are too many other factors that would cause associations
to break anyway.   But by providing a certain level of address-to-host 
binding stability, most applications would be spared the complexity
and security risks (etc.) of recovering from renumberings.

> that the operating system chose to use as the local end-point IP address

Well that gets back to the 'other factors' that I mentioned above.
one of the things that should inform the choice of that max reliable
lifetime constant is a survey of other sources of failure and an 
estimate of how likely they are to fail within that chosen lifetime.

However regardless of whether we pick a max reliable address lifetime 
constant or not OS designers and users clearly want to their systems 
to avoid picking an interface that is likely to fail.  For instance,
this argues for things like not having multiple interfaces configured
to talk to large networks.  (isn't it interesting how adding multiple
interfaces can degrade reliability?)  

(there are other ways to solve that problem also.  if interface A
goes down, have B register A's address with A's home agent via 
mobile IP)

> transport layer, which really is best and most appropriately solved at

The overhead of recovering from renumbering is close to requiring each
application to implement TCP at layer 7.   (for instance, if a connection
fails due to an address change, and you don't get a clean close, the app
has no idea whether the data it has sent to its peer really got there.
So the app needs explicit acks and to explicitly buffer all un-ack'd
data in case it needs to retransmit).

Do you really think that it is is optimal to burden all apps with this?

> Should it really be "dumb network, smart hosts, wise applications" ?

Why not have each layer doing its job without trying to outsmart the others?

Keith

p.s. another option would be to create extensions to TCP and UDP and
SCTP to securely handle renumbering.   I don't claim that this isn't
doable, and it might even be the best solution overall.  But offhand
it looks like a fair amount of hair, and IMHO it would be an even 
more drastic departure from the current architecture than trying to get 
the network to provide some assurance of address stability.
(the latter requires few protocol changes and mostly affects operations)
--------------------------------------------------------------------
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: Mark Smith <[email-masked]>
Date: 12 Nov 2002 14:03:43 +1100

On Tue, 2002-11-12 at 12:07, Keith Moore wrote:
<snip - and agree>
> data in case it needs to retransmit).

That's a good point, one I had overlooked.

> Do you really think that it is is optimal to burden all apps with this?

No I don't, although I'm probably only suggesting that applications that
don't want to be impacted by a TCP session failure (caused by
renumbering, interface failure etc) do need to implement this in some
way.

All the rest of the applications that don't have such a high
availability requirement should be able to accept very occasional TCP
failures due to renumbering events, interface failures etc, as long as
they didn't occur very regularly, which is and would be the case.

> > Should it really be "dumb network, smart hosts, wise applications" ?

I suppose what I'm really trying saying here is that for most
applications, the "dumb network, smart hosts" is enough. 

On the other hand, for the smaller number of very high availability
applications, the smart hosts are smart enough nearly all the time,
though not quite enough to be acceptable. In that case, an application
will need take some ownership of the reliability it requires.

A "wise application" (or rather developer) would weigh up its
reliability and availability requirements, and if TCP can't deliver
them, due to occasional interface failures, or occasional renumbering
events, then it will have to take measures of its own - with the
associated costs of implementing basic reliability mechanisms.

Hmm, even I thought it was just re-implementing TCP when writing the
last paragraph.

Do any mission critical applications today use TCP (retorical question)?
If so, how do they cope with interface failure tearing down TCP
sessions, other than just failing.There are ways of using networking
tricks like virtual interfaces inside a host etc to increase interface
and therefore IP address availability, but are there applications out
there today that take ownership of some level of their own reliability
requirements ?

> Why not have each layer doing its job without trying to outsmart the others?

True.

The issue we seem to be having is that by moving from pseudo-permanent
addressing to semi-dynamic addressing, we are reducing or taking away
one of the properties TCP has relied on.

site-locals addressing is trying to restore that property, but the
consequential complexity to many other areas (DNS, routers, security
etc) scares people.

Accepting that TCP sessions aren't going to live as long as they used to
when using global addressing, and giving the applications that have such
high TCP availability requirements some of that responsibility may be a
way of moving forward.

However, I can't see a typical organisation changing its global prefix
more than once every thirty days. If you do, maybe Mobile IPv6 is the
thing for you (I could be speaking out of turn here, I don't know much
about Mobile IPv6).

If you are running mission critical applications that require very long
lived TCP connections you are far more conservative in making network
infrastructure changes, addressing being one of them. You probably only
review your ISP contracts once every 12 months, and make it a
contractual decision that your globally assigned prefix will not change
during that period. If you wish to change ISPs, one of the associated
costs is mission critical down time, which you would weigh into the
costs-benefit of changing ISPs.

Mark.

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Nov 2002 23:57:41 -0500

> sessions, other than just failing.

well, it depends on the application.  for instance, SMTP can just
detect that the connection was broken and retry sending the entire
message.  but SMTP by its very nature buffers messages and has
explicit acks, so having SMTP cope with interface failures
requires little or no extra effort.

for that matter, most SMTP sessions are fairly brief.  apps that
use only brief connections won't experience many errors due to 
interface failures.  other sources of failure are often more
significant.

interactive apps cope with interface failures quite naturally by 
allowing the human user to retry the operation when it fails.

Keith

---

From: Andrew White <[email-masked]>
Date: Tue, 12 Nov 2002 16:30:45 +1100

Was: Re: Naming and site-local addresses

> interface failures.  other sources of failure are often more

Again we consider the problem of address selection for long-running apps...

Here are three models for address selection when both site-local and global
addresses are available.  Which (if any) is preferred:

* Leave it up to application, but recommend preferring global addresses:
  Pros:
    Pick the address with global scope.
  Cons:
    If we are using site-locals because global addresses are unreliable,
    then we are picking the less robust address.

* Leave it up to application, but recommend preferring local addresses:
  Pros:
    Site local addresses may persist where global addresses come and go.
  Cons:
    Default selection is not globally scoped.

* Provide addresses to application 'in order', defaulting to global first. 
Networks that consider their global addresses 'transient' may change
priorities to favour site local addresses.
  Pros:
    Doesn't require smart applications, but applications can override if
    they want.
  Cons:
    Need mechanism to propagate address selection preferences to hosts.

Note that short-running apps (say 10 minutes or less, to pull a number out
of the air) don't really care which address they use as long as it is valid,
which means these apps can reasonably prefer globals in multi-homed
situations (as long as the address is still within it's 'preferred'
lifetime.

Though there is the problem of how long to cache an address for.

-- 
Andrew White                [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Tue, 12 Nov 2002 08:49:07 +0000

> costs-benefit of changing ISPs.

I think this is one aspect of the problem, that it's hard to predict what
the renumbering requirements will be.  I recall this was one of the 
reasons back last summer that A6 bit the dust, that the requirements, and
likely future frequency of, renumbering wasn't yet understood.  I agree
at present for many organisations it's an annual price review issue.

Note though that site-locals are not just about avoiding pain in renumbering,
the same arguments apply for intermittent connectivity, or sites who connect
and receive a different prefix each time, e.g. if future IPv6 DSL providers
allocate dynamic /48's in the way that dynamic IPv4 addresses are allocated 
now.  That might be a daily event.

Tim

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Nov 2002 11:06:57 -0500

> addresses are available.  Which (if any) is preferred:

fourth model:

discourage use of site-locals when stable global addresses are available:

Pros: drastically reduces complexity of applications that would otherwise
      have to deal with site-locals

      doesn't artifically split the problem of apps dealing with 
      renumbering into local vs. non-local applications.
      
Cons: does not permit use of site-locals for avoiding the effects
      of renumbering for local applications.
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Tue, 12 Nov 2002 11:19:31 -0500

> What I want to know is why the concept "local" in
> the absense of enforceability (cf strong auth)
> isn't a thoroughly bogus concept. 

for the purpose of security, in any network of significant size,
it certainly is.

if site-locals are useful at all it is not because of security.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Nov 2002 08:16:00 -0800 (PST)

What I want to know is why the concept "local" in
the absense of enforceability (cf strong auth)
isn't a thoroughly bogus concept. Site-locals seem
to be trying to cling to that discredited
bogosity.

	  Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Nov 2002 09:28:58 -0800 (PST)

> if site-locals are useful at all it is not because of security.

   Well then, I guess I'm at a loss about why people would
   want to use site-locals for local services. If it's not
   for the possibility of access control, then what else
   is it?

	Mike

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Nov 2002 12:33:35 -0500

>    for the possibility of access control, then what else

valid use cases appear to be:

- for use in isolated networks (not connected to _any_ other network)

- local addresses that are stable across renumbering 

- addresses for intermittently-connected networks lacking a stable
  global prefix

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 12 Nov 2002 18:00:34 -0800

Michael Thomas wrote: 
>  > for the purpose of security, in any network of significant 
> size,  > it certainly is.  > 
Access control is one aspect of what SL provides. It is a clear address
space that service providers can put in bogon filters, and enterprise
managers can filter without having to go into detail about which
specific devices on a subnet are allowed in or not. It does not comprise
a full service security solution, and should not be sold as such. It is
simply a way to clearly articulate the difference between public and
private endpoints. 

What some on the list are having a hard time with is the concept that it
can be challenging to explicitly list every device that is not allowed
access from the public Internet when networks get to be large. This
problem gets even more complex when the nodes start moving around. For
the network manager, having a clean filter for FEC0/16 allows random
internal use addressing without concern that those systems will be
visible from the public side.

One might argue that for router requirements, there should be a MUST NOT
propegate the SL prefix into BGP. At a very minimum this should cause an
'are you sure' message. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Nov 2002 21:13:19 -0500

> Access control is one aspect of what SL provides. 

SL provides no benefits for access control that is not provided by
the ability to filter globals, and you need to do this anyway.

> and enterprise
> specific devices on a subnet are allowed in or not. 

SLs don't help you filter on a subnet basis - because they don't
give you any granularity beyond a 'site'.  If you want to filter
on a subnet basis you are back to explicit prefix matching.

*Of course* it can be a pain to manage filters for specific devices.
But this is every bit as much a pain with SLs as it is with globals.
SLs are orthogonal to this issue.

(and no, it's not acceptable to hand out globals and SLs to some devices 
on a network and only SLs to others - both because this breaks apps, 
and because it has security holes.)

> access from the public Internet when networks get to be large. 

What some on this list are having a hard time figuring out is
that SLs don't help you with this problem.

> propegate the SL prefix into BGP. At a very minimum this should cause an

One might argue that for application requirements, there should be a MUST
NOT mix SLs and globals on the same network.  At the very minimum the
application should display a warning message that the network is misconfigured.

Keith