Subject: [mobile-ip] R (router) bit in BUs

From: Francis Dupont <[email-masked]>
Date: Mon, 15 Jul 2002 13:58:41 +0200

Please put again the R bit in BUs, R is set to one if the MN is a router,
R is set to zero if it is a host *and* this bit is copied into Neighbor
Advertisements (in the R bit :-) sent by the Home Agent on the behalf
of the MN.

Regards

[email-masked]

---

From: "Kevin Miles" <[email-masked]>
Date: Mon, 15 Jul 2002 14:40:32 +0100

> Advertisements (in the R bit :-) sent by the Home Agent on the behalf
Seconded.

Kevin.

---

From: "T.J. Kniveton" <[email-masked]>
Date: Mon, 15 Jul 2002 07:09:16 -0700

FYI, we have specified this in draft-kniveton-mobrtr-02.txt  -- we did it
there because I don't know what the prospects for putting it back in the base
spec would be.
-TJ

---

From: Michael Thomas <[email-masked]>
Date: Mon, 15 Jul 2002 08:56:51 -0700 (PDT)

> Advertisements (in the R bit :-) sent by the Home Agent on the behalf

   I'll bite: what does something do with this information?

	      Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 16 Jul 2002 03:15:57 +0200

> Advertisements (in the R bit :-) sent by the Home Agent on behalf
    > of the MN.

=> we have the choice between either changing MN to MH in the specs or
putting the correct value in the R bit of NAs (:-).

Regards

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 Jul 2002 12:08:19 -0700 (PDT)

Francis Dupont writes:
 >  In your previous mail you wrote:
 > 

Francis, 

I'm afraid this is little too oblique for poor
moi. I'm sorry if I'm being dense here as I'm
unfortunately not asking rhetorical questions.
What would a neighbor do if it saw the R bit set
in the NA for my mobile node? Set up a default
route?

		  Mike

---

From: Francis Dupont <[email-masked]>
Date: Wed, 17 Jul 2002 02:40:50 +0200

=> the answer is in the RFC 2461 (grep for IsRouter).
The R bit is copied into the neighbor cache entry (in the IsRouter bit)
and the important case is the transition from 1 to 0 (i.e., a router
which becomes a host) when the node is used as a default router or
in a redirect...
Today all MNs are MHs but we should *not* close the door to MRs
just for one bit, and without any argument.

See you this afternoon?

PS: the R bit was added in I-D 08 (at my request) 
and lost in I-D 15 for an unknown reason (typo?).

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 16 Jul 2002 18:20:03 -0700

> and lost in I-D 15 for an unknown reason (typo?).

I think it was removed when Mobile Routers were considered out of
scope of the current spec. the prefix length field was also removed
from the BU at the same time for the same reason. I thought it was 
the WG decision to remove all references to mobile routers in the 
base MIPv6 spec. I dont remember.

anyway we have defined the 'R' bit in draft-kniveton-mobrtr-02.txt 
(and a separate prefix option)

Vijay

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 17 Jul 2002 10:47:38 +0900 (JST)

> base MIPv6 spec. I dont remember.

As far as I remember, the prefix length field was there to form
other's MN addresses like the link-local etc. Nothing to do with
MRs. This has always been missunderstood.

Concerning the 'R' bit, I think it should be good to keep it in the
draft, ND may later need to distinguish between the two. Keeping it
doesn't means MIPv6 is dealing with the specific actions to be taken
with MRs.

Thierry.
INRIA - WIDE - Keio University

---

From: Francis Dupont <[email-masked]>
Date: Wed, 17 Jul 2002 04:29:43 +0200

=> if this is the reason it is a bad one because a MR is two different
things:
 - a node which is a router too but in this context acts as a host
   (cf. the so called "host function" of routers in IPv4)
 - a mobile router in the NEMO termonology.
The R bit belongs to the first part so should *not* be removed as the
prefix length of second part.

=> in order to make the mobile router draft sound the R bit should be
reserved in the MN document, so there is no real argument against
to put it back into the MN document. Of course, this does *not*
applies to the prefix option.

Regards

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 Jul 2002 19:41:10 -0700 (PDT)

> which becomes a host) when the node is used as a default router or

   I'm still at a loss here because in order to
   be a real mobile router, you are going to
   either need to have a prefix delegated to you 
   by your home agent, or you are going to want to
   advertize routes to the HA's subnet, neither of which 
   MIP has any provision for. Right? I'm sorry if I'm
   being dense.

 > just for one bit, and without any argument.

   Ah, I don't see reserving the bit as closing the
   door on MR's. I see it as deferring it so that
   we get it right. Note that I don't have an issue
   with a "simple" MIP based MR solution so long as
   we understand the tradeoffs, and we are sensible
   with interactions; in particular, I remain concerned
   about RO's interaction.
 
 > See you this afternoon?

   It would be a very long swim...

	    Mike

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 16 Jul 2002 20:38:24 -0700

Hello folks,

As document editor, I was given the very clear message to
remove specification related to protocol for mobile routers.
I did this, even though my personal preference was to leave
it in because I always thought it was useful functionality.

> and lost in I-D 15 for an unknown reason (typo?).

It was not a typo.  It was according to very clear indication
after the Mobile Routers BOF, and I think according to
explicit instruction from the chairs but I didn't go checking
for e-mails on that.  I hope it does not get to be the case
that working as document editor does not entail keeping
paper trails for every word of every revision.

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 10:36:22 -0700

it is perfectly fine with me if the 'R' bit is put back in the 
MIPv6 spec.

Vijay

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 17 Jul 2002 21:14:58 +0300

One of the reasons why the R bit was taken away was
(and IMHO still is) security.  As far as I understand, the
RR method does not work for mobile routers, but I may
be wrong.  Furthermore, I haven't been following closely
enough, so I don't know if the base spec IPsec method
(for MN-HA security) is now clear enough so that the
R bit could be put back form MN-HA BUs.  But AFAIK we still
cannot use it for MN-CN BUs, due to these security
consideratiosn.

Maybe someone who has followed more closely the recent
security clarifications could add something here?

--Pekka

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 11:31:26 -0700

hi Pekka,

RR came much later. the 'R' bit was not there in draft 15. 

Vijay

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 17 Jul 2002 21:53:16 +0300

Vijay,

I stand corrected.  However, that fact doesn't change the
issue that RR does not work for mobile routers.  And that
AFAIK nobody has suggested how it could be extended, even.

Maybe I was confusing the issue with removing the routing
prefix, there I think the security issues were a part of
the story.  Or maybe not.

--Pekka

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 12:03:06 -0700

> AFAIK nobody has suggested how it could be extended, even.

thats true. I guess the NEMO BOF/WG would be investigating that.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Jul 2002 02:44:10 +0200

be wrong.

=> the R bit is for MN->HA BUs so your argument is irrelevant.

   Furthermore, I haven't been following closely
   enough, so I don't know if the base spec IPsec method
   (for MN-HA security) is now clear enough so that the
   R bit could be put back form MN-HA BUs.

=> MN-HA authorizes far more than the R bit so I don't believe
there is a security issue.

   But AFAIK we still cannot use it for MN-CN BUs, due to these
   security consideratiosn.
   
=> this doesn't matter.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Jul 2002 13:14:45 +0300

I'm looking at this issue and trying to understand what we
should do.

At the moment it looks like most folks who have expressed
their opinion are OK with putting the R bit back to the base
spec.

However, I have some doubts about this still. But let me first
describe the alternatives we have:

   1. No R-bit in base spec.
   2. R-Bit in an draft-kniveton-mobrtr-02.txt
   3. No R-bit, ever.

I think no one is arguing for #3 so we can only consider #1 and
#2. But what is their difference? One concern is that if the base
spec does not define this, then it becomes impossible to extend this
functionality later. This is obviously not an issue, as there is
reserved space in the BUs that can be used.

Another possible concern is that when base-only HA implementations
are deployed, it becomes impossible to deploy mobile routers as the
existing HAs do not support them. However, it seems that we need more
than the R bit for the mobile routers to work fully (see draft-kniveton
for the prefix option). So, it appears that whatever we do, we can't
have this functionality without also upgrading HAs.

Finally, Francis raised the concern that the router-with-a-host-function
is a separate issue from nemo-mobile-router, and that the R bit belongs
to the first one. I agree that the issues are separate, but I'm not sure
I understand why the R bit belongs to the former category. Presumably,
we are talking a case where a mobile host is a router at the same time.
That is, node M is a router on the foreign link with address F, and
is a mobile host with the address H at the same time. When at home,
M can even act both as a router and as a host using the same address H.
Even without the R bit, will something break? Obviously, without extensions
the MIPv6 protocol can't handle full router functionality. So, when M
is away from home, the HA will advertise H with the NA R bit set to 0.
So everyone on the home link will see that the router turned to a host.
If M is acting as a router on the foreign link, its router and host
addresses are going to be different, so I don't see a problem here either.

Other concerns? I can't think of any...

In conclusion, my suggestion is that we should define the R bit in
draft-kniveton and keep the base spec from increasing in length once
more... This is a small matter, however, and I have no special interest
in this so I can live with the R bit as well. Let me know if I missed
something above.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Sat, 27 Jul 2002 17:46:09 +0200

=> do you mean "R-bit in base spec".

   
=> I can't see a real difference between a reversed dedicated space
and #1. So #1 is simpler for the future.

   Another possible concern is that when base-only HA implementations
   are deployed, it becomes impossible to deploy mobile routers as the
   existing HAs do not support them.

=> don't forget that in IPv6 a node is either a host or a router
(exclusive "or").

    Presumably,

=> s/host/node/ !

   more...

=> as you still have to reserve the bit I don't buy this argument.

Regards