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

["Tony Hain" <[e-mail]>]

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