Subject: [mobile-ip] Re: [Q] Routing header

From: Thierry Ernst <[email-masked]>
Date: Tue, 29 May 2001 23:48:39 +0200

Hi all,

I have cc to the MIP WG because I think this discussion falls in its
interest.

Michael Thomas wrote:
> Steve Deering writes:
>  > At 1:03 PM -0700 5/29/01, Michael Thomas wrote:
>  > >   Where there is ambiguity, however, is in the host's construction
>  > >   of the routing header. Consider the situation where you have a
>  > >   mobile host behind a mobile router, each of which send binding
>  > >   updates to a correspondent node. How does the correspondent
>  > >   node know which order to put the routing headers in?
>  >
>  > Mike,
>  >
>  > You'll have to spend more time educating me on the details of the
>  > scenario you have in mind.  I would hope and expect that some
>  > encapsulation/decapsulation is going on at the mobile router,
>  > in which case you might have one routing header as part of the
>  > inner (encapsulated) packet, and one routing header as part of
>  > the outer (encapsulating) packet,
> 
>    I don't think there are any answers for this at
>    within mipv6.

This case was never really considered so far in any of the MIP specs. 
There is no answer to this specific case for the reason that mobile
networks are not explicitly addressed in any of the WG specs (indeed,
HMIPv6 which is a WG item does have a word about this and in this case
the CN wouldn't endup with 2 BUs).
 
>  > which is a different case than
>  > having multiple routing headers in a single extension-header
>  > chain.  I was assuming the question applied to the latter case,
>  > though the semantics of encapsulation case is also obvious.
> 
>    This is mostly a mipv6 issue, but suppose you have:
> 
>    MN------->MR------------------------>CN
> 
>    When the mobile node moves, it sends a BU to the CN.
>    When the mobile router moves, it too sends a BU to the CN.

This is only your scenario.   You could think of any scenario you want. 
Anyway, this is something I have already raised in the MIP WG and this
is presumably a case where MIPv6 would fail.

>    The CN now has a binding entry for both the mobile node
>    and the mobile router in its cache. Now if this
>    is going to work at all (which I think is the $64
>    "if") CN would need to construct a packet like:

But, first, why should the CN get two BUs ?  The CN is not a CN for the
MR.      Unless you refer to my draft 
http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt
which proposes that the MR be in charge of all the mobility management
of the mobile network.  But this is just a proposition, and it mainly
focus on the case where the nodes behind the router wired and fixed
nodes, not mobile nodes.

Then, your issue is rather a proposal for a solution, and it would be
better if you could first specify your solution, this would highly
highlight the issue you are trying to discuss.

> 
>     IP: dst=CoA(mr); RH: dst=CoA(mn); RH: dst=Home(mn);
> 
>    to prevent the packet from going through the
>    home agent of either the MN or MR.
> 
>    Yet, MN and MR might know nothing about each
>    other (the general case, I'd think) and CN
>    doesn't have any clue about the far end
>    topology either. It just has two binding
>    entries in its binding cache with no way
>    to correlate them, let alone set the proper
>    ordering.
> 
>  > In the absence of such specs, the Routing header contents will just
>  > continue to be provided manually, as in source-routed pings and
>  > traceroutes.
> 
>    Yes, I should make it clear that this isn't a
>    ipng ambiguity.
> 
>                 Mike
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------

--
* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/people/ernst/Welcome.html

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 29 May 2001 23:54:53 +0200

Steve Deering wrote:

> Last time I looked, the Mobile IPv6 spec dealt with mobile hosts only,
> not mobile routers.  If that's still true, it's unsurprising that
> it doesn't handle your scenario -- that would be the responsibility
> of a (future) Mobile IPv6 Router spec.

Steve, you are perfectly right - mobile routers and networks is not yet
a MIP WG item and the charter has never pretended to address this
issue.  May be it's time for it now.  What does the MIP WG think about
this ?  Any vote for it to be included in the charter for the next
meeting ?

> Presumably, to make this work, the BU from the mobile router to the CN
> would have to include the address prefix(es) reachable via the mobile
> router (i.e., the mobile subnet or larger aggregate that the mobile
> router is supposed to serve).  With that info, the CN would be able to
> tell that the mobile host address falls within the address block served
> by the mobile router, and could build the necessary header chain.

This is basically what my draft is proposing.  And in this case, the
MIPv6 spec needs redefine the "CN Operation".
(all is in the draft
http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt)

But there is an authorization issue that needs to be addressed as
everyone knows. 

Thierry.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 May 2001 15:53:53 -0700 (PDT)

> is presumably a case where MIPv6 would fail.

   I'm aware that this is only my scenario, but this is
   what I think a naive implementation would do. Ie,
   the mobile router would think it's supposed to send
   a BU when it see something come in from its home agent
   tunnel interface, the MN (or another MR) would
   think it's supposed to send a BU...

 > MR. 

   If the MR subtends a prefix and can send a BU
   which is legal in -13 as you know, it would 
   send a BU when it sees the packet on the HA
   interface. Otherwise, you'd have triangular
   routing at the MR.

     Unless you refer to my draft 
 > of the mobile network.

   Well, I think that we probably need to look at
   the induction from 1 to n otherwise the
   diagrams keep getting harder to parse each
   time we have to go through this :-)

 > highlight the issue you are trying to discuss.

   I'm not trying to propose anything, actually. I'm just
   pointing out that the current set of drafts won't
   work as they are currently stated to more than
   one level of mobility.

	     Mike

---

From: [email-masked]
Date: Wed, 30 May 2001 14:07:06 +0000

> But there is an authorization issue that needs to be addressed as

I also have another issue in mind. Usually mobile nodes as 
described in MIPv6 get an address assigned (c/o address), which is 
valid and routable at their actual temporary Internet access point.

Reading your draft, if a MR roams with the attached mobile network, 
the MR will get assigned a valid, routable c/o address at the new 
access point, while nodes of the mobile subnets keep their permanent 
static address (except if they are MNs, what you excluded for the 
first step). If one of the hosts at the mobile subnet now sends out 
some packets, it would use its permanent static IP address as source 
address, and therefore face the problem of ingress filtering (except 
the MR does some encapsulation work, but I havn't seen something like 
that in the draft).

Wolfgang

> Thierry.
##########################################################
##  Wolfgang Fritsche
##  Project Manager 
##         
##  IABG
##  Department for Communication Networks
##  Einsteinstr. 20
##  85521 Ottobrunn
##  Germany
##  
##  Phone: +49 89 6088 2897
##  Fax: +49 89 6088 2845
##  E-Mail: [email-masked]
##  Web: www.ipv6.iabg.de, www.iabg.de
##########################################################

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 31 May 2001 13:53:36 +0200

>    think it's supposed to send a BU...

I agree that a MN behind the MR is supposed to send a BU, but I disagree
that the MR "is supposed to" do it as well.   First, the MR is not the
final destination of the packet.  Second, if you think about a naive
implementation, MR would send a BU to the sender that appears in the
inner header in the encapsulated packet, i.e. the CN of MN "behind"
MR.   And what would contain the BU ?  A binding between the MR's home
address and its COA.   This does not give much usefuk information to the
CN.  You would end up with a cache at the CN containing:

MR home address -> MR coa
MN home address -> MN coa

CN uses MR's coa if it ever want to communicate with MR directly (very
unlikely)
CN uses MN's coa for packets it wants to send to the MN.      No problem
at the CN, although your datagram is going to be routed via the MR's HA
(because MN's coa has the same prefix has the MR's home address.   The
issue is that the HA does not know how to redirect  (same reason as
explained in my draft)

Then, the issue your are describing (including two addresses in the
routing header) would not happen with a naive implementation of MRs.  
If any proposal would advocate such use of the routing header, I think
it should also describe how this should be done.

>    which is legal in -13 as you know,  it would

Sorry, I don't catch you here. Could you refine ?

>    work as they are currently stated to more than

This is right, but this is not the purpose of any existing draft to
address more than one level of mobility.   More than one level of
mobility needs it's own set of drafts.

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 31 May 2001 14:00:37 +0200

Hi Wolfgang,

> the MR does some encapsulation work, but I havn't seen something like

OK, I will add a section in my revise draft.   

I am not sure that IPv6 routers should perform ingress filtering (recent
discussions did not give me a concrete answer ...) ; otherwise my idea
is that MR would indeed encapsulate all outgoing packets.    

Thanks to have pointed this out.
Thierry.

---

From: [email-masked]
Date: Thu, 31 May 2001 14:41:31 +0000

> is that MR would indeed encapsulate all outgoing packets.    

At least if you have a look in the MIPv6 draft, chapter 2, support 
for coexistence with ingress filtering is pointed out as one benefit 
of MIPv6 compared to MIPv4, so there seems to be no reason for 
stopping ingress filtering in IPv6.

Encapsulation could work around this problem, but you have to 
investigate  the influence of this encapsulation to authentication, 
firewalls, and overhead added to narrow band links.

Wolfgang

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 May 2001 09:59:12 -0700 (PDT)

Thierry Ernst writes:
 > that the MR "is supposed to" do it as well.   

   If this is true, what is the purpose of putting a subnet prefix
   into the BU at all? How does the MR (ignoring MN for the moment)
   eliminate triangular routing through its HA? Surely the purpose
   of adding the prefix wasn't just to say that MN was reachable
   at a range of IP addresses.

 > First, the MR is not the
 > CN.  

   Remember it's the MR's home _prefix_, not address. That's
   what my reference to the -13 draft was about below. 

 > it should also describe how this should be done.

   I think the problem here is that the addition of prefix
   to the BU is not sufficient to support mobile routers,
   and as such it's open to interpretation what the
   implementation should do.

   While I generally like the addition of subnet prefix
   to BU's (mainly because it treats BU's like the routing
   updates that they are), it may actually be better to
   get the MIP WG to take the whole subject of MR's up
   as working group item and delete it till then because
   it may unfairly prejudice the final outcome.

	  Mike

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 31 May 2001 19:56:04 +0200

>    what my reference to the -13 draft was about below.

Mickael,

You might probably not read the mipv6-13 draft correctly.   The purpose
of the home_prefix in the MIPv6 spec. is for the Home Agent to defend
ALL home addresses of the MN on the home link (link local, site local,
global), not for support of Mobile Routers.    This has ab-so-lu-te-ly
nothing to do with the Mobile Router case.   If it has, may be I should
rather going to grew vegetables or follow English lessons (don't know
which one would be the best though :-)

The prefix you are refering to is therefore included by the MN to inform
its HA (not its CNs) [remember the 'H' bit that stands for 'Home
Registration" ?] about the size of the prefix, not to manage mobile
routers and networks.   In addition, whatever the mobile (host or
router), a binding is ALWAYS established between the 128-bits Home
Address of the mobile and it's 128-bits Careof Address.   The only place
were is mentioned a binding between a prefix and a 128-bits address is
my draft.  Otherwise, the contribution of my draft would be pointless. 
Why should I introduce a new sub option if there is already all we need
in the MIPv6-13 draft ? 
 
>    implementation should do.

IMHO, there is nothing to miss-interpret since the addition of prefix in
the BU is not in the MIPv6-13 draft.  What may be miss-interpreted by
implementation is redirection at the HA of packets intended to nodes
behind the MR (problem described in my draft - sorry, I always refer to
my draft, but I do not want to explain everything in each email and this
is clearly described there)
 
On the other hand,  I advocate that my draft may be miss-intrepreted,
but this is only version-1 and I clearly stated that my proposal does
not consider MN behind the MR (BTW, I did state this exaclty for the
reason you were describing at the beginning of this thread - what would
the CN do with 2 BUs, one from MN, and one from MR)

>    as working group item 

This is exactly what many people already want (to list just a few of
them Hesham Soliman, Francis Dupont, Claude Castelluccia, Glenn Morrow,
and may others).   May be I should ask for it more explictly.

> and delete it till then because

And delete it ?  Sorry, I do not understand.   (may be I should really
take English lessons then :-)

There is a problem with mobile routers because this special case has
never been considered seriously (or not at all) in any of the existing
MIP WG specs.   My interpretation is that implementers should only
implement the MIP WG drafts for hosts.  Another set of specs. is
required for mobile routers.

Thierry.