Margaret Wasserman wrote:
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?
Send a name.
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?
Any app that sends topology locator information without understanding
the topology is broken.
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.
In simple two party apps there will be no such confusion. If
applications insist on passing around information that they don't
understand, they will create the confusion you suggest.
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.
It is very likely that no error will be received, because most site
network managers block ICMP at the border anyway.
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.
If NodeB doesn't walk the list, it is broken. If the application on
NodeA passed topology locator information without understanding the
topology, it is broken.
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?
Since it didn't get a SL back for NodeB, there is no reason to provide
NodeB with a SL address. Those addresses are defined to be filtered, and
from the information that NodeA has, NodeB is on the outside of the
filter.
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.
Changes that should be required anyway. Applications MUST NOT pass
around topology locator information without understanding what they are
doing.
- 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.
If applications work from names, there is no need for a layer violation.
The stack is perfectly capable of figuring out the correct address to
use if it has a name to work from. Passing topology locator information
without a firm grasp of the topology is the architecturally unsound
issue here.
- 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 absolutely does. When an app knows there is an insufficient scope, it
also knows that the connection is designed by the network manager to
fail. If the app developer can't figure out what to do when it is known
that a prospective member can't participate, it is not our job to spell
that out.
- 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.
I can't parse this. In any case if an application is passing topology
locator information, it has to understand the topology.
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".
Either the addresses are ambiguous to the routing protocol, or it can
deal with them. If they are ambiguous, there is no way to pass them
around, so the 'need' is fabricated at best.
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.
DNS passes around topology locators. Keeping it ignorant of the real
topology is the poor architectural choice. If the app developers really
want to keep the apps simple, they must pass around names, and let the
infrastructure component tasked with keeping track of reality do the
work. If apps insist on passing around topology locators rather than
relying on DNS, they must understand the reality of the network they are
describing.
(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.
Applications that pass around topology locators without understanding
topology are broken, and need modification. Cost is their burden for
choosing a broken approach.
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).
Two party apps don't have any problem here. It is only the multiparty
apps that insist on passing information they don't understand that have
these problems.
Thoughts?
The IAB really needs to take a hard look at the disconnect between the
DNS as defined for the network of 20 years ago, and the real networks
deployed today. No matter which prefix is used, there are addresses that
have a scope limited by the filtering rules of the network manager.
Passing these around only serves to confuse apps, because DNS claims
that the node is accessible by a particular topology locator, but there
is a filter that prevents it. If the DNS were to return an NX, the
application would immediately know that it couldn't get there.
Tony