Subject: [mobile-ip] MIPv6: Problem with site-local prefixes an Type 2 Routing Header?

From: Ville Nuorvala <[email-masked]>
Date: Tue, 14 Jan 2003 15:00:59 +0200 (EET)

Hello everybody!

I'm not sure if anyone else has noticed this already, but at least to
me there seems to be a bit of a problem if the MN's home link has both global
and site-local prefixes.

I see two scenarios:

Scenario MN <-> HA:

1. The MN sends BU to HA whith s=0 using a global home address and CoA.
2. The HA registers all derived addresses (also sl) to the global CoA.
3. HA sends a positive ACK to the global home address used by MN in BU.
4. HA sends packet to MN's sl address and routes it using RH 2
   with registered CoA.
5. MN drops packet while parsing RH 2 because the scope of CoA
   is greater than the scope of the home address.

Scenario MN <-> CN:

1. as above
2. as above
3. as above
4. Site-local CN sends a packet to MN's sl address.
5. HA tunnels the packet to MN (assuming it is not administratively
   prohibited).
6. MN believes it has a valid binding for the site-local home address and
   initiates RR using global CoA.
7. If RR successful (COTI, HOTI, COT and HOT all reach their destinations,
   i.e. MN, CN and HA are assumably on the same site) MN sends BU to CN.
8. CN sends packet to MN and routes it using RH 2 with registered CoA.
9. MN drops packet while parsing RH 2 because the scope of CoA
   is greater than the scope of the home address.
10. If binding expired go to 4. else go to 8.

Hmm... Come to think of it the same thing also happens if the MN does a
s=1 binding for a sl home address using a global CoA.

Have I missed something in the draft, or is this a true problem?

If it turns out to be a problem, I might have a possible solution:

A MN MUST discard a packet with Type 2 Routing Header if the CoA is of
greater scope than the home address and it doesn't originate from the HA.

A MN MUST NOT initiate RR using a CoA of greater scope than the home
address.

A CN MUST NOT accept a binding if the CoA is of greater scope than the
home address used in the BU.

If the MN believes it has a binding with the CN it should get a BE status
1 when it tries to send the next packet to it, so i guess the CN can silently
ignore the BU.

Opinions, anyone?

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: [email-masked], phone: +358 (0)9 451 5257

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Jan 2003 16:17:35 +0200

> 1. The MN sends BU to HA whith s=0 using a global home address and CoA.

Great, another issue with S=0 involved...

>    is greater than the scope of the home address.

See Section 4.6 which states "Site-local addresses may be usable on
networks that are not connected to the Internet, but this
specification does not define when such usage is safe and when
not." So your scenario starts out from a situation which is
explicitly mentioned to be outside the scope of the current
specification.

> 1 when it tries to send the next packet to it, so i guess the CN can silently

The above may in fact work, but the WG has been discussing the
specifics of site-local details for a long time, and we always
ended up with finding problems and holes in the rules. This is
why we ended up restricting the site-local addressability to
a minimum.

So I think the current specification does work on this point,
to the extent that it promises to do so. That being said, I
do think that Section 10.4.2 should have a default=off for
site-local forwarding. Text below.

   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;
   ...
   Multicast packets addressed to a multicast address with
   scope larger than link-local but smaller than global
   (e.g., site-local and organization-local~\cite{rfc2373}),
   to which the mobile node is subscribed, SHOULD NOT be
   tunneled to the mobile node by default. This behavior
   MUST be configurable to allow it to be enabled.

Jari

---

From: Ville Nuorvala <[email-masked]>
Date: Wed, 15 Jan 2003 15:13:55 +0200 (EET)

> Great, another issue with S=0 involved...

Well not just S=0. As I mentioned the explicit S=1 (or S=0) registration
of a site-local home address using a global care-of address also causes
problems. The specification allows this, but the protocol breaks if you
do it.

Scenario MN <-> HA #2:

1. The MN sends BU to HA whith s=1 (or s=0) using a site-local home
   address and global CoA.
2. The HA registers the sl home address to the global CoA.
3. HA sends positive ACK to MN's sl home address and routes it using RH 2
   with registered CoA.
4. MN drops ACK while parsing RH 2 because the scope of CoA
   is greater than the scope of the home address.
5. Go to 1.

Our MIPL MN implementation actually suffers from this, since it doesn't
currently support the S=0 home registration and will perhaps never do so.
Any volunteers willing to implement it for us? :)

If our MN wanted the HA to protect a site-local address, it would have to
follow the above procedure, which, as I said, is broken.

> explicitly mentioned to be outside the scope of the current

Yes I'm aware that this thing might be a bit outside the scope of the
current specification, but I have at least pointed out a couple of cases
where the proposed protocol will fail.

> why we ended up restricting the site-local addressability to
As long as the use of mixed scope prefixes on the same link isn't
forbidden by the draft, I think we should try make it work.

Alternatively ban the use of mixed scope prefixes and addresses in the
base draft (and for instance mandate that MN and HA ignore smaller scope
prefixes if bigger scope prefixes available on home link) and write a
separate draft that covers the issues involved with their use.
What do you say?

>    MUST be configurable to allow it to be enabled.

This sounds like a good idea as the MN also SHUOLD NOT use site-local
home or care-of addresses. Even though it doesn't fix the MN <-> CN
problem, at least it sweeps it under the carpet for the moment. The problem
with sweeping things under the carpet is that you might have quite a
collection of dust bunnies there the next time you look under it. :)

The MN <-> HA scenarios remain unchanged, but would be fixed if the
MN handled Routing Header Type 2 as I proposed earlier. As the MN
already has a binding with the HA, should it not accept all traffic from
it?

Ville

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 15 Jan 2003 10:47:09 -0800

hi Ville,

> collection of dust bunnies there the next time you look under it. :)

I disagree. we have to wait till the IPv6 WG to decides what it
wants to do with site-locals. MIPv6 does not guarantee anything, 
when the HoA is site-local. OTOH, it make no sense prohibiting 
the use of site-locals as home address. suppose the MN nevers 
leave a site (maybe a corporate inranet), but roams all over the 
site, site-local HoAs work. no problem.

I think SHOULD NOT is good enough. there is no reason for a 
MUST NOT.

Vijay

---

From: Ville Nuorvala <[email-masked]>
Date: Thu, 16 Jan 2003 14:18:30 +0200 (EET)

On Wed, 15 Jan 2003, Vijay Devarapalli wrote:

> the use of site-locals as home address.

I wasn't about to ban site-locals, I just thought this problem should be
fixed for real.

If there is interest in the mobileip WG, I could perhaps start charting
the scenarios with different combinations of globals and site-locals
so we get a clearer picture of the issues involved.

> suppose the MN nevers
They work as long as the CoA is also site-local. With a global CoA there
clearly are problems, as I pointed out in my original mail.

A short list of obvious problems with mixed scope addresses:

1) HA will not be able to get any packets (including binding acks)
   through to MN's site-local HoA if it has been registered using a global
   CoA since MN will discard them.

2) MN is unable to get valid binding for site-local HoA using global
   CoA unless it does S=0 binding.

3) Doing forced S=1 bindings MN can only protect its site-local HoA if it
   uses site-local CoA and MN is still on same site as HA, leaving
   it in a worse position than by using S=0.

All above problems would be fixed just by allowing greater scope CoA
for packets originating from HA. Is there any reason for not allowing it?

4) If the HA tunnels site-local traffic, CN will not be able to get any
   traffic through to MN once CN has a global CoA site-local HoA binding
   with it.

This one is trickier and I'm not conviced my initial solution necessarily
works. As it is also at least temporarily "fixed" by turning off site-local
tunneling by default, I guess I'm ok with Jari's proposition.

Ville

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 16 Jan 2003 13:38:53 +0100

> I think SHOULD NOT is good enough. there is no reason for a 

Looks like there are enough warnings already.
So the way I read these exchanges is that we're keeping the
SHOULD NOT, but adding the default=off configurability in Section 10.4.2 as
suggested by Jari:

Note that this is *already* reflected in the pre(20) version:
http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#ha-deliver

Issue closed?

-gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 16 Jan 2003 13:49:03 +0100

> I wasn't about to ban site-locals, I just thought this problem should be

They should, but the working group already decided we weren't going
to do it for the base spec:

 From section 4.6 on Site-Local Addressability:

" this specification does not define when such usage is safe and when not."

> so we get a clearer picture of the issues involved.

There is interest, but the way I interpret issue 162 is that it's
closed, and we won't pursue further for the base spec.

-gabriel