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

From: "Greg O'Shea" <[email-masked]>
Date: Thu, 13 Feb 2003 09:02:19 -0000

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.
Okay, I had not realized that significant energy had already been spent.

But out of curiosity, and without trying to solve the generality of
site-locals, I wonder if we can make some simplifying assumptions for
MIPv6:
1) we ignore Site-Local foreign nets for purposes of forming CoA, i.e.
we only have to consider home SL zones
2) the HA serving the home site-local zone uses its global HA addr to
serve SL registrations i.e. the addresses (HA,HoA) known to the MN have
scope (global,site-local) respectively.

From (2) the MN knows an association between a global prefix and the
home SL zone. This allows the MN to disambiguate the home SL zone from a
foreign zone using the same SL prefix, which the MN must do in order to
known whether it is at home or abroad for its SL HoA. (An IF attached to
the home zone will see RA for the HA's global prefix and an IF attached
to a different zone with same SL prefix as the home SL zone will not see
RA for the HA's global prefix.) This also allows the MN to detect that
multiple IF are attached to the home SL zone. 

It seems that (2) is legit for the HA from 10.3.1 because the SL and
global prefix are both onlink to the HA. I guess that was deliberate.
But it would alter the current handoff logic to do the
(global,site-local) comparison and it would need testing.

Personally I hate to see something as loose as the current text in a
spec, but I guess you had better leave things as they are until the
adventurous have more to report.

Greg
>-----Original Message-----
>From: Jari Arkko [mailto:[email-masked]] 
>Sent: 12 February 2003 20:59
>To: Greg O'Shea
>Cc: [email-masked]
>Subject: Re: [mobile-ip] MIPv6 v20 site-local addresses
>
>
>Greg O'Shea wrote:
>
>> 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.
>
>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: Thu, 13 Feb 2003 09:21:18 -0800

Greg -

> we only have to consider home SL zones

Section 4.6 already says:
"Therefore, site-local addresses SHOULD NOT be used as home or care-of
addresses."

> scope (global,site-local) respectively.

I'd hesitate to create this artificial restriction. Actually, the home agent
address is one of the few addresses in Mobile IPv6 that it makes sense to
implement as a site-local scope address. For example, consider wireless
service provider that wants to deploy Mobile IPv6 on their network. All of
their wireless links could be considered to belong to the same site. In that
case, if they make their home agents only accessible via site-local scope
addresses in that site, this affords them greater security and control over
that part of their network.

The site-local scope address prefix has been or is in the process of being
redefined to be more like the global scope address prefix, in fact the
intent is that the site-local scope prefix for a given link exactly match
the global scope prefix assigned to that link (except for the first 16 or so
high-order prefix bits, in the site-local scope case "fec0").

> multiple IF are attached to the home SL zone.

Please let's avoid trying to solve site-local scope in this draft. Let's
wait until implementors have more experience with it.

> adventurous have more to report.

This is my opinion too, although the current looseness w/ regards to
site-local doesn't bother me as much.

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Feb 2003 19:49:48 +0200

> site-local doesn't bother me as much.

Yeah. So why don't we stick to SHOULD NOTs in the places that
I suggested... that leaves the spec pretty clear and still
allows folks to go do their site local stuff if they really
need and they understand what they are doing?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Feb 2003 22:28:30 +0200

Ed,

An additional clarification to the issue. So what
we are proposing is *not* to remove the ability to
configure the tunneling of site-local addresses.
We are removing the *requirement* to do so. Implementors
can still use site-locals; just that they have to
understand the full implications and carefully
weigh the case (see RFC 2119). I think implementors
will understand the need to make the forwarding
and other aspects of site-locals configurable in
their products, right Ed?

So, the proposed text change was:

to

Jari

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 13 Feb 2003 12:45:49 -0800

Jari -

This is (from a purist standpoint) exactly the change I was hoping you would
not make to the spec... but:
I'm OK with you removing as many features from the specification as you
want, it just makes my work (as an implementor) easier because then there is
less to implement.

I still think I identified a valid use case, but then VPN should allow you
to communicate with site-local scope peers on your home network while you
are away from home so use VPN w/ IPv6 instead of MIPv6 if you need that
functionality.

> I think implementors

I'm doing a generic implementation of the MIPv6 protocols, we sell source
code not hardware. We don't go off into proprietary-land, so if there is no
requirement for a config switch on the HA to enable site-local scope
tunneling to the MN we certainly won't bother to have our MN implementation
support site-local scope home addresses since that will just increase code
size w/out any apparent benefit. I'll update my design document accordingly.

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

> Sent: Thursday, February 13, 2003 12:29 PM
> To: Ed Remmell
> Cc: Greg O'Shea; [email-masked]