Subject: [mobile-ip] MIPv6 v20 site-local addresses

From: "Greg O'Shea" <[email-masked]>
Date: Wed, 12 Feb 2003 19:05:10 -0000

Packets addressed to the mobile node's site-local address SHOULD NOT be
tunneled to the mobile node by default, but this behavior MUST be
configurable to enable it; [10.4.2]
Why is it a good idea for site-local to be configurable? Text elsewhere
states that we don't know how to deal with site-local in MIPv6 [4.6,
10.4.2] and I agree with that so for a change I won't bother to point
out examples of entanglement. How can we specify configurable use of
site-local when we can't specify what could or should happen when it's
enabled? Especially when you're multi-homed. For now I think site-local
should be out. It can be reviewed e.g. at DS time or better still as a
separate doc when we understand what it means.

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 12 Feb 2003 11:18:51 -0800

I have identified the following MN use case for site-local scope:

"Access Internal System behind Corporate Firewall
In some cases, the user wants to communicate with an internal system behind
the corporate firewall. The internal system in this case has a site-local
scope address. The user has configured (either auto- or manually) a
site-local scope address with a matching prefix on their virtual home
interface. When they send to the site-local address of the internal system,
we will find a prefix match on the virtual home interface, and because the
address is site-local scope we will always use the MN-to-HA tunnel to send
to that destination. Alternatively, if we don’t find a prefix match but if
they specify a source address which is configured on the virtual home
interface, that will cause us to select the virtual home interface as the
outgoing interface, and then in the virtual device send function on that
interface we will see that the destination address is site-local scope and
so we must send it using the HA tunnel in this case."

So, I think that being able to participate in site-local scope communication
with nodes on its home network while the mobile node is on a foreign link is
a potentially useful feature that should not be removed.

BTW, "virtual home interface" is what we use to store/configure the MN's
home addresses on when it is attached to a foreign link. This is associated
a virtual device driver, which uses the MN-to-HA tunnel to tunnel packets
sent to site-local destination addresses that originate on that interface.
We use the source IP address of the packet in our routing decision to select
the correct outgoing interface, when mobile node functionality is enabled.
Probably more than you wanted to know ;-)

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Greg O'Shea
Sent: Wednesday, February 12, 2003 11:05 AM
To: [email-masked]
Subject: [mobile-ip] MIPv6 v20 site-local addresses

Packets addressed to the mobile node's site-local address SHOULD NOT be
tunneled to the mobile node by default, but this behavior MUST be
configurable to enable it; [10.4.2]
Why is it a good idea for site-local to be configurable? Text elsewhere
states that we don't know how to deal with site-local in MIPv6 [4.6, 10.4.2]
and I agree with that so for a change I won't bother to point out examples
of entanglement. How can we specify configurable use of site-local when we
can't specify what could or should happen when it's enabled? Especially when
you're multi-homed. For now I think site-local should be out. It can be
reviewed e.g. at DS time or better still as a separate doc when we
understand what it means.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Feb 2003 22:59:21 +0200

> separate doc when we understand what it means.

This issue too is something that has been debated in the group
during the last half a year; a scaled down version of the discussion
that was started in the IPv6 working group. We attempted multiple
times to try to formulate the spec so that site-locals would
work well. This proved quite hard, almost as hard as defining where
and how site locals should be used in IPv6. In the end, we decided
to make site locals a SHOULD NOT, but still left the door open
for adventurous implementors to try it at their own risk. And
yes, the intention is that a separate spec would talk about this
later. Perhaps after IPv6 decides what they want to do.

But the text that you quoted is funny -- we would we build
support for something that is a SHOULD NOT? I would change the
text

   "... SHOULD NOT be tunneled to the mobile node by
    default, but this behavior MUST be configurable to
    enable it ..."

to

   "... SHOULD NOT be tunneled to the mobile node ..."

This still leaves the door open to those who want to go
there, but doesn't burder the spec with details about
what to do for site-locals. And we still clearly
indicate that these kinds of addresses should be
filtered away when tunneling. Ok?

Jari

P.S. Ed, you must be an adventurous implementor ;-)
P.P.S. Be careful with same addresses in home and visited
networks.

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 12 Feb 2003 13:42:56 -0800

Jari -

>    "... SHOULD NOT be tunneled to the mobile node ..."

I'm not in favor of this change. I'd like the specification to call for this
behavior to be configurable on the HA, which is currently the case:
	"but this behavior MUST be configurable to enable it".

I don't care that the default is to disable tunneling of site-local scope
traffic to the MN, just that it is configurable so that it could potentially
be enabled later.

The rest of the specification seems to permit the usage scenario I
described. Section 10.6.1 "Aggregate List of Home Network Prefixes" does not
prohibit the home agent from including site-local scope home prefixes in the
list of prefixes that it advertises to the mobile node using the ICMP Mobile
Prefix Advertisement Message.

I do believe the use case I presented is a valid real-world scenario that it
would be nice for MIPv6 to support, that of communicating with nodes on your
home network over the MN-to-HA tunnel while away from home and those nodes
are protected behind a corporate firewall so they can only be accessed using
a site-local address. As a MN away from home, you still belong to the site
that your home network belongs to, at least it would be nice if you could
belong to that site (i.e. over the MN-to-HA tunnel).

> P.S. Ed, you must be an adventurous implementor ;-)

We want to provide a robust impementation. I think this is a valid use case.

One of the reasons given for why L=1 (in the BU) is needed is because in
some cases (MLD, DHCPv6) there is link-local scope traffic tunneled over the
MN-to-HA tunnel. So, you want to allow link-local scope tunneling but
prohibit site-local scope tunneling? It seems like the use of site-local
scope home addresses to communicate with peers on your home network is
something we should try to support over the MN-to-HA tunnel.

> P.P.S. Be careful with same addresses in home and visited

We restrict the MN to using the MN-to-HA tunnel when sending packets that
have a site-local scope source address. The intent is to support site-local
communication with peers on their home network through the HA.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com