Subject: RE: LL1, LL23

From: "Christian Huitema" <[email-masked]>
Date: Sat, 22 Feb 2003 16:28:15 -0800

Erik asked for some concrete references about "what breaks when applications inadvertently stumble on site local addresses". There are at least two simple examples: application running on multi-homed hosts, and applications passing addresses to other hosts.
 
Suppose a multi-homed host with two interfaces, e.g. an Ethernet to the regular network of the organization, and a Blue Tooth link for ad hoc connectivity. When the application issues a "connect" or a "send to", the stack tries to route the packet to the "right interface". If the same subnet (169.254/16) is reachable through two interfaces, the stack is likely to pick a default interface, which leads to failures if the target is actually connected to the other link. By reducing as much as possible the usage of link local addresses, one can reduce this failure mode. In particular, in this example, things will work much better if LL addresses are only configured on the "ad hoc" link.
 
Consider now a host using an address passing application, such as for example VoIP using SIP. The host has just one interface. When the application wants to set up a VoIP call, it reads the IP address of the interface, and document it in the SDP payload of a SIP message; the peer will then send RTP packets to that address. If the interface has several addresses, the host needs to pick one; if the application is not LL aware and the interface has both an LL address and a routable address, the application is likely to pick at random. The SIP packet will often travel beyond the local link; if the application placed the LL address in the RTP payload, the VoIP call will fail. This failure will not happen if the host did not configure an LL address.
 
The natural consequence of these arguments is that hosts should not be required to configure LL addresses if they have a global address; this is the rationalefor rejecting LL19. LL1 or LL23 are somewhat stronger: instead of not forcing LL addresses on unwilling hosts, it forces even willing hosts to not configure LL addresses if they have a routable address. For that, we need a stronger motivation than just the host convenience; after all, if all applications were fully LL aware, they would choose the routable address when available, or they would specify the outgoing interface when using LL addresses; a host that only support LL aware applications could choose to keep the LL addresses around, even if we don't believe that this is a good idea.
 
The review of site local addresses in the IPv6 working group outlined another class of concern, address leakage; this was based on our experience with RFC 1918. Despite the statements in RFC 1918, we observe that non-global addresses actually leak on the global Internet. For example, the DNS root regularly recieves requests for the PTR record of RFC 1918 addresses; sites receive connection requests sourced with RFC 1918 addresses; Dynamic DNS updates sometimes result in RFC 1918 addresses appearing in DNS records, etc. Obviously, all of this results from bugs, and we could decree that software should not have bugs, but you will probably agree that this is unrealistic.
 
Since leakage hurts the rest of the Internet, the robustness principle dictates that we limit the risk of LL addresses leaking. This is achieved, by and large, by reserving such addresses to ad hoc networks, and by not using them on connected networks. Which translate in a requirement to select either LL1 or LL23. There seems to be a preference for the text of LL23, with some revisions.
 
-- Christian Huitema

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Feb 2003 09:36:08 +0200

Thanks Christian,

I found this more useful than anything that's been said so far.

On Sun, 2003-02-23 at 02:28, Christian Huitema wrote:
> Suppose a multi-homed host with two interfaces, e.g. an Ethernet to
> the regular network of the organization, and a Blue Tooth link for ad
> hoc connectivity. When the application issues a "connect" or a "send
> to", the stack tries to route the packet to the "right interface". If
> the same subnet (169.254/16) is reachable through two interfaces, the
> stack is likely to pick a default interface, which leads to failures
> if the target is actually connected to the other link.

This is a very good point.

Our implementation can handle the ambiguity if the application uses the
IPv6 socket API with IPv4-mapped addresses and qualifies them with a
scope identifier. However, it is clear that pure IPv4 applications would
have a problem.

> By reducing as much as possible the usage of link local addresses, one
> can reduce this failure mode.

Just reducing the usage of LLs is not an adequate solution. What you
suggest below would be:

>  In particular, in this example, things will work much better if LL
> addresses are only configured on the "ad hoc" link.

It seems clear that, in a multihomed host, the use of LLs should
generally be limited to a single interface. This is a pretty awkward
limitation of LLs. I can see where the choice of interface might depend
on the current connectivity situation and how this might lead to people
clamoring for LL23.

However: how the LL interface is chosen should be left up to the OS
vendor or device manufacturer, since the right thing to do may depend on
the device. I think normative language will do more harm than good here.
The vendors should be warned about the problem but allowed to do their
own thing.

It's clear to me now that the specification should have some text
describing what should happen, when the LL address needs to be
configured/unconfigured.

However, I'm firmly opposed to the idea that the specification should
mandate *when* to do that.

If LL23 were reformulated in those terms I would be willing to accept
it.

> Consider now a host using an address passing application, such as for
> example VoIP using SIP. The host has just one interface. When the
> application wants to set up a VoIP call, it reads the IP address of
> the interface, and document it in the SDP payload of a SIP message;
> the peer will then send RTP packets to that address. If the interface
> has several addresses, the host needs to pick one; if the application
> is not LL aware and the interface has both an LL address and a
> routable address, the application is likely to pick at random. The SIP
> packet will often travel beyond the local link; if the application
> placed the LL address in the RTP payload, the VoIP call will fail.
> This failure will not happen if the host did not configure an LL
> address.

Judging by this, SIP telephony is also likely break in any multihomed
configuration where one of the interfaces is on an isolated network or
where RFC1918 addresses are being used. In order to make things work in
that context, the application has to be able to answer the question:
"What is a good source address for this destination address?". There are
several possible ways to deal with this (in the context of LLs) in an
implementation without requiring LL1/LL23:

a) Ted made a good suggestion: the SIOCGIFCONF ioctl (or equivalent)
should return LL addresses only if explicitly requested by the
application. This would make certain that only applications that know
how to handle LLs would get them as result.

b) Keith suggested that some applications try to pick an address from
the interface, where the default route points to. If the LL address and
the 169.254/16 on-link prefix are configured on a separate virtual
interface, this technique will keep on working (also for SIP).

c) An explicit "What is a good source address for this destination
address?" syscall can be added to the OS to solve this. [Actually, a
simple UDP connect(dst)+getsockname() might work on many operating
systems]. This, of course, only helps those applications smart enough to
do it.

None of the above measures require LL1 or LL23.

> The natural consequence of these arguments is that hosts should not be
> required to configure LL addresses if they have a global address; this
> is the rationalefor rejecting LL19.

Ok. I see this would be desirable for multihomed hosts. For single homed
hosts there's no problem having both LL and routable addresses on the
same interface provided that other measures, such as a) - c) suggested
above, are implemented. The OS vendor should have the freedom to make
their own implementation choices.

In fact, the address leakage concerns you outline below make me think
that we should seriously reconsider LL19. Slight loss of functionality
in multihomed configurations seems like a small price to pay for
curtailing the address leakage problems.

>  LL1 or LL23 are somewhat stronger: instead of not forcing LL
> addresses on unwilling hosts, it forces even willing hosts to not
> configure LL addresses if they have a routable address. For that, we
> need a stronger motivation than just the host convenience;

Agreed, stronger justificaton is needed.

>  after all, if all applications were fully LL aware, they would choose
> the routable address when available, or they would specify the
> outgoing interface when using LL addresses; a host that only support
> LL aware applications could choose to keep the LL addresses around,
> even if we don't believe that this is a good idea.

There are cases where this would clearly be possible, such types of
restricted devices where the set of applications is known. The
implementation techniques I outlined above also work well with a more
random set of applications.

> The review of site local addresses in the IPv6 working group outlined
> another class of concern, address leakage; this was based on our
> experience with RFC 1918. Despite the statements in RFC 1918, we
> observe that non-global addresses actually leak on the global
> Internet. For example, the DNS root regularly recieves requests for
> the PTR record of RFC 1918 addresses; sites receive connection
> requests sourced with RFC 1918 addresses; Dynamic DNS updates
> sometimes result in RFC 1918 addresses appearing in DNS records, etc.
> Obviously, all of this results from bugs, and we could decree that
> software should not have bugs, but you will probably agree that this
> is unrealistic.

Software SHOULD not have bugs. :) But yes, this is clearly an issue.

> Since leakage hurts the rest of the Internet, the robustness principle
> dictates that we limit the risk of LL addresses leaking. This is
> achieved, by and large, by reserving such addresses to ad hoc
> networks, and by not using them on connected networks. 

Ultimately this boils down to how serious the leakage problem is seen to
be and choosing a remedy of equal strength.

It seems extremely strange to me that address leakage did not seem to be
any kind of a problem when we were considering LL19. Accepting LL19
would have done a great deal to limit address leakage, by limiting the
use of LL addresses only to hosts that are *compliant*. In this light,
rejecting LL19 seems like a pretty huge mistake.

As a purely hypothetical example, suppose the company I work for (Nokia)
starts deploying a hundred million v4LL capable devices on a yearly
basis. Do you think hacks like LL1 or LL23 will be sufficient?

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Sun, 23 Feb 2003 11:45:07 +0100

Christian,

[WG chair hat off]
Thank you for your excellent post.  (If only we had listened to
your warnings back in Pittsburgh!)

Christian Huitema wrote:
> Erik asked for some concrete references about "what breaks when 
 > applications inadvertently stumble on site local addresses".
 > There are at least two simple examples: application running on
 > multi-homed hosts, and applications passing addresses to other hosts.
>  
 > the regular network of the organization, and a Blue Tooth link for
 > ad hoc connectivity. When the application issues a "connect" or a
 > "send to", the stack tries to route the packet to the "right
 > interface". If the same subnet (169.254/16) is reachable through
> two interfaces, the stack is likely to pick a default interface, 
 > which leads to failures if the target is actually connected to
 > the other link. By reducing as much as possible the usage of
 > link local addresses, one can reduce this failure mode.

        B (169.254.33.22)
        |
        A Telnet 169.254.33.22 ???
        |
        C (169.254.33.22)

This is an excellent example of a problem.  How in particular is
section 3 insufficient?  Should we open a new issue to limit the
applicability of the protocol to a single link at the same time?

> Consider now a host using an address passing application, such 
 > as for example VoIP using SIP. The host has just one interface.
 > When the application wants to set up a VoIP call, it reads the
 > IP address of the interface, and document it in the SDP payload
 > of a SIP message; the peer will then send RTP packets to that
 > address. If the interface has several addresses, the host needs
 > to pick one; if the application is not LL aware and the
 > interface has both an LL address and a routable address,
 > the application is likely to pick at random. The SIP packet
 > will often travel beyond the local link; if the application
 > placed the LL address in the RTP payload, the VoIP call
 > will fail. This failure will not happen if the host did not
 > configure an LL address.

I think this is an excellent justification for a host preferring
to use a non-link-local scope address over a link-local scope
address if it has both.

One issue I have with the example you gave is that either the
host has a link-local address and is using a proxy on the local
link or the host has a global address and can use whatever.  If
the host is using a proxy, doesn't SIP increasingly support
operation over address space boundaries?  I know experts I can
refer to about this.

This is a specific case of a well known application being pushed
into support of ALGs, right?  But once
  - we have an ALG and
  - those with enough clue to install a proxy at all will also know
    how to configure them to traverse address space boundaries

don't a lot of the arguments against specific protocols breaking
due to address scoping lose their force?

> The natural consequence of these arguments is that hosts should 
 > not be required to configure LL addresses if they have a global
 > address; this is the rationale for rejecting LL19. LL1 or LL23 are
 > somewhat stronger: instead of not forcing LL addresses on
 > unwilling hosts, it forces even willing hosts to not configure
 > LL addresses if they have a routable address. For that, we need
 > a stronger motivation than just the host convenience; after all,
 > if all applications were fully LL aware, they would choose the
 > routable address when available, or they would specify the
 > outgoing interface when using LL addresses; a host that only
 > support LL aware applications could choose to keep the LL
 > addresses around, even if we don't believe that this is a
 > good idea.
>  
> The review of site local addresses in the IPv6 working group 
 > outlined another class of concern, address leakage; this was
 > based on our experience with RFC 1918. Despite the statements
 > in RFC 1918, we observe that non-global addresses actually
 > leak on the global Internet. For example, the DNS root
 > regularly recieves requests for the PTR record of RFC
 > 1918 addresses; sites receive connection requests sourced
 > with RFC 1918 addresses; Dynamic DNS updates sometimes
 > result in RFC 1918 addresses appearing in DNS records,
 > etc. Obviously, all of this results from bugs, and we
 > could decree that software should not have bugs, but you
 > will probably agree that this is unrealistic.

This is an excellent point.  Thank you for pointing this out.

> Since leakage hurts the rest of the Internet, the 
 > robustness principle dictates that we limit the risk
 > of LL addresses leaking. This is achieved, by and large,
 > by reserving such addresses to ad hoc networks, and by
 > not using them on connected networks. Which translate
 > in a requirement to select either LL1 or LL23. There
 > seems to be a preference for the text of LL23, with
 > some revisions.

What specific revisions do you support?

Thanks sincerely,

Erik