RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

[Margaret Wasserman <[e-mail]>]

Hi Tony,

At 11:51 AM 3/31/2003 -0800, Tony Hain wrote:
>Margaret Wasserman wrote:
> > Of course, in the case of site-local addresses, you don't
> > know for sure that you reached the _correct_ peer, unless you
> > know for sure that the node you want to reach is in your
> > site.
>
>Since the address block is ambiguous, routing will assure that if you
>reach a node it is the correct one. This FUD needs to stop!

I believe that you have misunderstood my point...  I'll try to explain
further, although our friends in the applications area may be able
to give better examples.

Let's assume that there is a FooBar server in SiteA.  If another
node in SiteA (NodeA) is communicating via a multi-party application
to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar
server in SiteA, what does it do?

If this is IPv6 with site-local addressing, NodeA may be speaking
to the FooBar server using a site-local address.  What happens if
NodeA sends that site local address to NodeB?

NodeB tries to reach the FooBar server at the SL address that
points to the FooBar server in SiteA.  But, within SiteB, that
same address may point to a non-existent subnet, to a non-existent
node or to an existing node in SiteB.  Scoped routing doesn't stop
NodeB from reaching the wrong node, it guarantees that NodeB
_will not_ reach the right node and _may_ reach the wrong node.

The type of failure that NodeB will receive is different in each case.
If the address points to a non-existent subnet or node, an ICMP error
may or may not be generated and no connection will be established
(timeout), but if there is an existing node in SiteB with the same
address, NodeB will receive some type error from that node (the node
that NodeB _thinks_ is the FooBar server), such as port not
available, connection reset, or an application-level error. Or,
worse yet, NodeB may not receive any error at all, and may never
know that it was speaking to the wrong node.

Now, what if NodeA has a list of addresses for the FooBar server
(perhaps obtained through the use of split DNS) that includes
both site-local and global addresses?  Perhaps NodeA will send
the whole list of addresses to NodeB.  If NodeB tries the
site-local address first (as current IPv6 address selection rules
indicate) it will not reach the FooBar server.  However, it could
have reached the FooBar server using a global address.

Perhaps, you believe that NodeA should include intelligence inside
the application that knows NOT to send site-local addresses to NodeB
if NodeB is not in the same site?  If so, how does NodeA find out that
NodeB is not in the same site?

One proposal is that NodeA should only send addresses to NodeB that
are of the same or larger scope as the IP address that NodeA is currently
using to reach NodeB.  But, this has problems, too:

         - It requires some fairly complicated changes to existing
                 applications to make them work properly on IPv6.
         - It requires applications to make address selection
                 choices based on the addresses in use at the
                 network layer.  Since there is an increasing desire
                 for applications to be unaware of the addresses used
                 at the network layer, and to survive changes in
                 those addresses (see SCTP, SIP, Mobile IP, etc.), this
                 is not an architecturally sound mechanism.
         - It doesn't give a good answer for what the application
                 should do if it only has one address available
                 for the referral, and it is not of sufficient scope.
         - It may not interact well with access control mechanisms
                 that depend on using a site-local address to
                 reach services, as it errs on the side of not
                 sending site-local addresses, even when they
                 may be valid.

There are, IMO, three major problems (and several minor problems)
with the use of site-local addressing on globally connected networks:

         (1) Routing protocol issues/complexity, such as the need to
                 handle ambiguous addresses in routing exchanges and
                 the need to maintain site "convexity".  These problems
                 can be avoided by avoiding site-border routers and
                 site-border nodes (as in the "moderate" proposal),
                 AND by placing site borders on OSPF/IS-IS area
                 boundaries or on AS boundaries.
         (2) Institutionalizing the need for split DNS.  I understand
                 that some network administrators choose to use split
                 DNS today, but that doesn't meant that we want to build
                 a requirement for split DNS it into the IPv6 architecture.
                 IMO, requiring the DNS infrastructure to be aware of and
                 enforce topology boundaries is a poor architectural choice.
         (3) The need for upper-layer protocols (transport, session and
                 application-layer protocols) to include address
                 selection logic to decide when to pass (and not to pass)
                 site-local addresses in upper-layer communications.  This
                 requires modification to existing application protocols
                 and implementations, and is an unnecessary source of
                 added complexity and cost for IPv6 implementations.

We have yet to come up with any workable model for the use of
site-local addressing on connected networks that does not exhibit
problems (2) and (3).

Thoughts?

Margaret